Lately there’s been some interest in build processes among various people — Vellum was announced a while back, Ben has been looking for a tool and looking at Fabric, and Kevin announced Paver. At the same time zc.buildout is starting to gain some users outside of the Zope world, and I noticed Minitage as an abstraction on top of zc.buildout.
A while ago I started working on a build project for Open Plans called fassembler. I think the result has been fairly successful and maintainable, and I thought I’d share some of my own reflections on that tool.
Update: what we were trying to accomplish
I didn’t make it clear in the post just what we were trying to do, and what this build system would accomplish.
Our site (openplans.org) is made up of several separate servers with an HTML-rewriting proxy on the front end. We have a Zope server running a custom application, Apache running WordPress MU, and some servers running Pylons or other Python web applications for portions of our site. We needed a way to consistently reproduce this entire stack, all the pieces, plugged together so that the site would actually work. Two equally important places where we had to reproduce the stack are for developer rigs and the production site.
Our code is primarily Python and we use a lot of libraries, developed both internally and externally. Setting up the site is primarily a matter of installing the right libraries and configuration and setting up any databases (both a ZODB databases and several MySQL databases). We use a few libraries written in C, but distutils handles the compilation of those pretty transparently.
For this case we really don’t care about build tools that focus on compilation. We don’t care about careful dependency tracking because we are compiling very little software.
make doesn’t make sense
Update 2: If you think the make model makes lots of sense, read the preceding section — it makes sense for a different problem set than what we’re doing.
We initially had a system based on BuildIt, which is kind of like make with Python as the control code. It wasn’t really a good basis for our build tool, and I think it added a lot of confusion, compounded by the fact that we weren’t quite sure what we wanted our build to do. Ultimately I think the make model of building doesn’t make sense.
The make model is based on the idea that you really want to save work. So you detect changes and remake things only as necessary. For compilation this might make sense, because you edit code and recompile a lot and it’s tedious to wait. But we are building a website, and installing software, and none of that style of efficiency matters. make-style detection of work to be done doesn’t even save any time. But it does make the build more fragile (e.g., if you define a dependency incorrectly) and much harder to understand, and you constantly find yourself wiping the build and starting from scratch because you don’t trust the system.
The metaphor for the new build system was much simpler: do a list of things, top to bottom. There’s no effort into detecting changes in the build, or changes in the settings, or anything else.
Do things carefully
In the build system almost all actions go through the filemaker module. This is kind of a file abstraction library. But the goals are entirely different than convenience: the goal is transparency and safety. In contrast Paver uses path.py for convenience, but I’m not sure what the win would be if we used a model like that.
filemaker itself is heavily tied to the framework that it’s written for, specifically user interaction and logging. Most tasks just do things, and rely on filemaker to detect problems and ask the user questions. For example, every time a file is written, it checks if the file exists, and if it has the same content. If it exists with other content, it asks the user about what to do. It doesn’t overwrites files without asking (at least by default). I think this makes the tool more humane as the default behavior for a build is to be careful and transparent. The build author has to go out of their way to make things difficult.
Many zc.buildout recipes will blithely overwrite all sorts of files which always made me very uncomfortable with the product. It’s the recipes in zc.buildout which do this, not the buildout framework itself, but because buildout made overwriting the easy thing to do, and didn’t start with humane conventions or tools, this behavior is the norm.
What I think filemaker most accomplished was the ability to do file operations while also asserting the expected state of the system, and so makes build bugs noticeable earlier instead of getting a build process that finishes successfully but creates a buggy build, or having an exception show up far from where the error was originally introduced.
Also, because it won’t overwrite your work in progress this has saved the build from engendering deep feelings of hatred in cases when it might overwrite your work in progress. It’s hard to detect this absence of hatred, but I know that I’ve felt it with other systems.
Update: a corollary: ignore no errors
One question you might wonder about: why not a shell script? We did prototype some things as shell scripts, but we’ve consistently moved to Python at some point, even things that seemed really trivial. The problem with shell scripts is they have horribly bad behavior with respect to errors. Ignoring errors is really really easy, noticing errors is really hard.
This is absolutely unacceptable for builds. Builds must not ignore errors. The build may mostly work despite an error. It might be totally broken, but the error message is lost in all sorts of useless output. The error message probably makes no sense. The context is lost. No suggestion is given to the user.
When builds work, that’s great. Build do not always work. They always fail sometimes, and some poor sucker (usually in some hot potato-like arrangement) has to figure out what went wrong. You have to plan for these problems.
Everything in the build tries to be careful about errors. All places where it is not, it is a bug. The resolution isn’t to see something appear to work, but create a broken build, and say "oh, you forgot to set X". The resolution is to make sure when you forget to set X it gives you an error that tells you to set X.
This is one of the more important and more often ignored principles of a good build/deployment system. Maybe it’s gotten better, but when I first used zc.buildout (very early in its development) the poor handling of errors was by far the biggest problem and it left me with a bad taste in my mouth. easy_install and setuptools in general is also very flawed in this respect.
Log interesting things
I tried to make a compromise between logging very verbosely, and being too quiet. As a user, I want to see everything interesting and leave out everything boring. Determining interesting and boring can be a bit difficult, but really just require some attention and tweaking.
To make it possible to visually parse the output of the tool I found both indentation and color to be very useful. Indentation is used to represent subtasks, and color to make sections and warnings stand out.
The default verbosity setting is not to be completely quiet. Silence is a Unix convention that just doesn’t work for build tools. Silence gets you interactions like this:
$ build-something target-directory/
(much time passes)
Error: cannot write /home/ianb/builds/20080426/target-directory/products/AuxInput/auxinput/config/configuration.xml
Why did it want to write that file? Why can’t it write that file? Is the build buggy? Did I misconfigure it? Does the directory exist?
The typical way of handling this is either to run the build again with logging setup or otherwise make it more verbose, or to get in the habit of always running it verbose.
Mixing code and configuration
BuildIt, which we were using before, had the ability to put variables in settings, and you could read an option from another section with something like ${section/option}. It was limited to simple (but recursive) variable substitution, and had some clever but very confusing rules that created a kind of inheritance.
I liked the ability to do substitution, but wasn’t happy with the compromise BuildIt made. I wasted a lot of time trying to figure out the context of substitutions. So, I saw two directions. One was to remove the cleverness and just do simple substitution. This is the choice zc.buildout made. The other was to go whole-hog. With a bit of trepidation I decided to to go for it, and I made the choice to treat all configuration settings as Tempita templates. All configuration is generally accessed via config.setting_name, and that lazily interpolates the setting (it took me quite a while to figure out how to avoid infinite loops of substitution). Because evaluation is done lazily settings can depend on each other and be overridden and have lots of code in defaults (e.g., a default that is calculated based on the value of another setting), and it works out okay. Most settings just ended up having a smart default, and as a result very little tweaking of the configuration is necessary.
Somewhat ironically the result was a kind of atrophying of the settings, because no one actually set them, instead we just tweaked the defaults to get it right. Now I’m not entirely sure what exactly the "settings" are setting, or who they should really belong to. To the build? To the tasks? While this is conceptually confusing, in practice it isn’t so bad. This mixing of code and configuration has been distinctly useful, and not nearly as problematic to debug as I worried it would be. In some ways it was a way of building lambda into every string, and the lazy evaluation of those strings has been really important. But it’s not clear if they are really settings.
Would normal string interpolation have been enough (e.g., with string.Template)? I’m pretty sure it wouldn’t have been. The ability to do a little math or use functions that read things from the environment has been very important.
Managing Python libraries
fassembler uses virtualenv for building each piece of the stack. Generally it creates several environments and installs things into them — it doesn’t run inside the environments itself. This works fine.
zc.buildout in comparison does some fancy stuff to scripts where specific eggs are enabled when you run a script. Each script has a list of all the eggs to enable. You can’t install things or manage anything manually, even to test — you always have to go through buildout, and it will regenerate the scripts for you. zc.buildout was implemented at the same time as workingenv (the predecessor to virtualenv), and I actually finished virtualenv with fassembler in mind, so I can’t blame zc.buildout for not using virtualenv. That said, I don’t think the zc.buildout system makes any sense. And it’s really complicated and has to access all sorts of not-really-public parts of easy_install to work.
Isolation is only the start. easy_install makes sure each library’s claimed dependencies are satisfied. You might then think easy_install would do all the work to make the stack work. It is nowhere close to making the stack work. setup.py files can/should contain the bare minimum that is known to be necessary to make a package work. But they can’t predict future incompatibilities, and they can’t predict interactions. And you don’t want all your packages changing versions arbitrarily. If you work with a lot of libraries you need those libraries to be pinned, and only update them when you want to update them, not just because an update has been released.
So for each piece of the stack we have a set of "requirements". This is a flat files that indicates all the packages to install. They can have explicit versions, far more restrictive than anything you should put in setup.py. It also can check out from svn, including pinning to revisions. This installation plan can go in svn, you can do diffs on it, you can branch and copy and do whatever. Maybe at some point we could use it to keep cached copies of the libraries. For now it mostly uses easy_install (and python setup.py develop for checkouts).
In parallel we have a command-line program for just installing packages using files like this, called PoachEggs. I want to make this better, and have fassembler use it, but I mostly note it because it implements a feature that can "freeze" all your packages to a requirements file. You take a working build and freeze its requirements, giving explicit (==) versions for packages, and pin all the svn checkouts to a revision, so that the frozen requirements file will install exactly the packages you know work.
An alternative to this is what the Repoze guys are doing, which is to create a custom index that only includes the versions of libraries that you want. You then tell easy_install to use this instead of PyPI. It works with zc.buildout (and anything that uses easy_install), but I can’t get excited about it compared to a simple text file. I also want svn checkouts instead of create tarballs of the checkout — I like an editable environment, because the build is just as much to support developers as to support deployment.
The structure
A big part of the development of fassembler was nailing down the structure of our site, and moving to use tools like supervisor to manage our processes. A lot of these expectations are built into the builds and fassembler itself. This is part of what makes the build Work — the pieces all conform to a common structure with some basic standards. But this isn’t the build tool itself, it’s just a set of conventions.
I don’t know quite what to make of this. Extracting the conventions from the builds leads to a situation where you can more easily misconfigure things, and the installation process ends up being more documentation-based instead of code-based. We do not want to rely on documentation, because documentation is generally because of a flaw in the build process that needs explaining. It’s faster for everyone if the code is just right. Maybe these conventions could be put into code, separate from the build. The abstraction worries me, though — too much to keep track of?
What we don’t get right
The biggest problem is that fassembler is our own system and no one else uses it. If someone wants to use just a piece of our stack they either have to build it manually or they have to use our system which is meant to build all our pieces together with our conventions. There’s some pressure to use zc.buildout to make pieces more accessible to other Zope users. We’ve also found things that build with zc.buildout that we’d like to use (e.g., setups for varnish).
We haven’t figured out how to separate the code for building our stuff from the build software itself. There’s a bootstrapping problem: you need to get the build code to build a project, and so it can’t be part of the project you are building. zc.buildout uses configuration files (that aren’t code, so they lack the bootstrap problem) and it uses recipes (a kind of plugin) and has gone to quite a bit of effort to bootstrap everything. virtualenv also supports a kind of bootstrap which we use to do the initial setup of the environment, but it doesn’t support code organization in the style of zc.buildout.
Builds are also fairly tedious to write. They aren’t horrible, but they feel much longer than they should be. Part of their length, though, is that over time we put in more code to guard against environment differences or build errors, and more code to detect the environment. But compared to zc.buildout’s configuration files, it doesn’t feel quite as nice, and if it’s not as nice sometimes people are lazy and do ad hoc setups.
The future
We haven’t really decided, but as you might have noticed zc.buildout gets a lot of attention here. There’s quite a few things I don’t like about it, but a lot of these have to do with the recipes available. We don’t have to use the standard zc.buildout egg installation recipe. In fact that would be first on the chopping block, replaced with something much simpler that assumes you are running inside a virtualenv environment, and probably something that uses requirement files.
Also, we could extract filemaker into a library and recipes could use that. Possibly logging could be handled the same way (the logging module just isn’t designed for an interactive experience like a build tool). Then if we used other people’s recipes we might feel grumpy, since they’d use neither filemaker or our logging, but it would still work. And our recipes would be full of awesome. The one thing I don’t think we could do is introduce the template-based configuration. Or, if we did, it would be hard.
That said, there is a very different direction we could go, one inspired more by App Engine. In that model we build files under a directory, and that directory is the build. Wherever you build, you get the same files, period. All paths would be relative. All environmental detection would happen in code at runtime. Things that aren’t "files" exactly would simply be standard scripts. E.g., database setup would not be done by the build, but would be a script put in a standard location.
This second file-based model of building is very much different than the principles behind zc.buildout. zc.buildout requires rebuilding when anything changes, and does so without apology. It requires rebuilding to move the directories, or to move to different machines. Using a file-based model requires a lot of push-back into the products themselves. Applications have to be patched to accept smart relative paths. They have to manage themselves a lot more, detect their environment, handle any conflicts or ambiguities, being graceful about stuff like databases, because the files have to be universal. In an extreme case I could imagine going so far as to only keep a template for a configuration file, and write the real configuration file to a temporary location before starting a server (if the server cannot be patched to accept runtime location information).
So this is the choice ahead. I’m not sure when we’ll make this choice (if ever!) — build systems are dull and somewhat annoying, but they are no more dull and annoying than dealing with a poor build system. Actually, they are definitely less dull than working with a build system that isn’t good enough or powerful enough, or one that simply lacks the TLC necessary to keep builds working. So no choice is a choice too, and maybe a bad choice.
No related posts.
“But it does make the build more fragile (e.g., if you define a dependency incorrectly) and much harder to understand, and you constantly find yourself wiping the build and starting from scratch because you don’t trust the system.”
Dependency tracking is a feature, not a source of fragility. If you’re wiping the build because you don’t trust the system, perhaps you should be looking in the direction of the programmer and not the tools she uses.
Does dependency tracking matter that much for Python programs, where installation is mostly copying files and possibly a C extension or two? Any accumulated savings of time from avoiding redundant copying could be eaten up by the first two-hour debugging session that concludes “oh, I changed this thing but that thing over there didn’t get regenerated.” We’re not talking about GCC or Emacs, where a build can take a half hour.
Thanks for posting this. I’m working on build scripts for some Django projects (on Windows), and the parts on being humane got me thinking.
You’ll want to take a look at Vesta from DEC (later Compaq) for ideas on how to retain make’s efficiency while making dependencies impossible to miss. What you have done here is not clearly better than make. Vesta is.
I work with Ian at TOPP. I want to make explicit one of the most important things about fassembler. It’s not just a build tool, it’s a deployment tool. This is where the don’t-overwrite-without-prompting feature really shines, and some other things Ian didn’t mention like automatically checking your configuration files into subversion. This has greatly reduced the amount of pain involved in deploying our rather large openplans.org stack.
The downsides: There are a lot of TOPP-specific conventions baked in, as Ian noted. We don’t expect that you’re going to download fassembler today and start using it for your own projects. Even if you use subversion, and even if what you want to build is the openplans stack, you’re really not going to want to check your configuration into TOPP’s svn repository, so the first thing you have to learn is the option to use another repository, which right away suggests that maybe this tool isn’t really aimed at you. Even within TOPP, the always-check-config-into-svn feature is a bit silly at times (dev sandbox builds, buildbot builds and the like).
We also are a very nix-centric shop, so we have no Windows story at all.
And I agree that builds do feel more tedious to write than I would like. We’ll keep working on that.
Some of the other flaws are just inherent in the underlying infrastructure, like python packages being hosted all over the place. I don’t like that our build failure rate is a function of the number of external websites hosting packages we need. It’s actually 1-(average_uptime**n). In practice it’s high enough to be quite annoying, especially since a given site’s downtime tends to be clumpy.
Maybe a caching HTTP proxy would help somewhat, or something like zc.buildout’s local egg cache. In practice we end up manually dumping copies of eggs into our local apache and configuring the build to look there.
>So you detect changes and remake things only as necessary. For compilation this might make sense, because you edit code and recompile a lot and it’s tedious to wait.
The pure dependency based is the reason why make is much better tool than say ant, nant, etc…
It’s great when properly written makefile completes in
Yes, perhaps one of the reasons people are picking up on file dependencies is that I started right in without describing what we’re doing. There’s a lot of different “build tools” that do radically different things. Finding the overlap between Paver and Fabric would be hard.
This build tool is for deploying our stack, for production, testing, and development. It doesn’t do anything special for remote deployments (unlike Capistrano). It isn’t focused on compiling because nearly everything we have runs from source (as a result we’d save no time figuring out file dependencies).
Note to “X X”: You’re assuming efficiency is a big problem for our use cases. It’s been a total non-issue.
EDIT: partly this is because, as Ian noted, most of our stuff isn’t compiled. For instance, a build from scratch of our most complex product (opencore) takes less than ten minutes on old hardware, the bulk of which is download time. Rebuilds take less than a minute; largely this is because we delegate to tools that already handle dependency checking (easy-install, make, etc).
For the few things we install from big tarballs (like Zope), we just manually added a check for an up-to-date tarball. This takes a few lines of code, whereas in Make it’d “just work”. But there are relatively few cases where we care, so this hasn’t been much burden.
Ian, regarding your idea of pushing support for relative paths into upstream dependencies: That sounds like a nice beautiful simple world, but I just don’t see how that’s an achievable goal in practice. We might get patches accepted by some upstream projects, assuming we have the time and smarts to do so; that has some inherent value, but as long as there’s one holdout that we really need, we’re stuffed.
Not to say that we wouldn’t want the build to run faster… but to make it run faster we’d do work the package installation which is where a lot of the time goes, i.e., changes to easy_install, caching download dependencies, maybe using PyPI XMLRPC, or things like that.
While this approach is obviously working for them, I can’t help but think it could cause problems in the future. You’ve essentially linearized your dependency graph, and while the current linearization is presumably correct, any change to the way the system works could render it incorrect, silently or with a big bang. Explicitly encoding your dependencies can be hard, but in my experience it results in a much less fragile, much more easily understandable system. I’ve even used [graphviz](http://www.graphviz.org/) to visualize dependency graphs, which can make clumsy architecture easier to spot.
We don’t have a dependency system because we run all steps on every build. Any skipped steps are done on a case-by-case basis with careful checks specific to the step we are skipping. I really can’t imagine anything a dependency system could accomplish. If you can imagine something, then you are probably thinking of a different kind of tool than ours, one that serves a different purpose and is used for different tasks.
I’m pretty glad you noticed minitage as i don’t have even released it officially yet.
The zc.buildout rebuilding’s habit is one of the main things that make me made minitage. I’m happy with zc.buildout but rebuilding everything is simply not acceptable. So i just do it in an atomic way now. It builds one thing, at one place, that’s all. So we can afford to rebuild something entirely as just that will be rebuilt.
Although minitage is working at the moment, it can be rough to be used by a classical user.
Why?
Because the documentation is not really all up to date to the new version.
Because it is made by a geek :p
Because this is inspired by complicated tools (Gentoo’s portage, or other ports systems.)
What can that brings to you ?
Minitage lives on top of virtualenv, virtualenv will set its prefix.
More than just installing python libraries, it installs also system software pieces like postgresql or even python. Its final goal is to deploy a project from start to end in a re-usable manner.
Free from zc.recipe.egg. I didn’t like too the approach of that recipe. Offline mode / local indexes were very problematic with it. So i implemented a recipe for minitage that borrowed code from zc.recipe.egg at the difference that it ll search in the cache before looking online for dependencies. That means if you have putted the egg inside the cache prior from this buildout execution, there will be no Online access at all, no index check.
SVN (and others scms, ftp or http urls) checkouts can be up to you too with that recipe. See this buildout template: http://tinyurl.com/5c93lq You can have it with paster and minitage.paste (minitage.geodjango template) It uses custom GeoDjango egg that is not on pypi, and svn checkout to get the sources to build :)
An enhanced CMMI build recipe wich integrates well with minitage for building “compiled” dependencies and interlink with other stuff installed into minitage.
More than an abstraction, minitage is in spirit a meta package manager. It does nothing by itself and relies on ‘install methods’. At this time, only buildout is available but it is as simply as to make recipes to implement install methods. Its only goal is to maintain dependencies to schedule the build process order and the install layout : http://www.minitage.org/doc/rst/spec.html#the-installation-layout.
For the log verbosity, minitage is pretty loud :p .
NA: The documentation moved to http://www.minitage.org/doc/rst/, you seemed to use a pretty old link.
Hi Ian,
Thanks for writing up all of your thoughts about build tools (and for mentioning Paver). I should note that Paver uses a modified path.py that supports “dry-run”. It could easily be extended further to support prompting, which is something I just hadn’t thought of.
I’ve been considering zc.buildout integration as my next step for Paver, but I’m going to think about minitage and the process you’ve created around virtualenv, because I have noticed some of the same annoyances with zc.buildout that you have. One thing that made buildout integration appealing to me is that there are so many recipes that people have written for a variety of things. However, I think that many of these recipes exist simply because that’s the only way to write code for a buildout, which is buildout’s most annoying trait, imho. (I believe someone has written a recipe that lets you put some code in your buildout config file, but eww…)
By the way, so far I have not at all regretted my decision for Paver’s configuration and task definition to be entirely in Python. For Python programmers, there’s very little that is unclear about what will happen. (The trickiest things at present are those areas around distutils integration.)
Paver supports lazy evaluation of configuration items via callables (lambdas, generally). This has worked fine for my needs thus far.
On the whole, I’m quite happy to see all of this activity around build tools, because it has been a source of annoyance (obviously for many).
Kevin
Thanks for sharing this.
I’ve had the same problem – building a tool to deploy [developers.org.ua](http://www.developers.org.ua) site (uses Pylons, Django, WordPress, Openads and lots of other smaller libs).
Thus your reflections with fassember/zc.buildout were helpful to “diff against”.
I use Tempita to write deployment-specific files, such as paste .ini or apache vhost files. Configuration data stored in YAML format; there is a common.yaml which holds shared config info plus a .yaml file per each deployment, which contain deployment-specific options like database creds.
Each build/deployment is “self-contained”, that is, all files are put under a specific dir. The system env is configured (with symlinks or direct configuration) to use corresponding bits from the deployment. E.g. crond looks for its script under DROOT/environ/cron.* dirs.
My main “issue” with it – since it’s built by me (in-house) it means I have to maintain it. ;) Therefore I’d like to migrate/use some existing tool if/when it is available. Some [capistrano for python](http://maxischenko.in.ua/blog/entries/118/capistrano-for-python/) or whatever it would be.
So you detect changes and remake things only as necessary. For compilation this might make sense, because you edit code and recompile a lot and it’s tedious to wait.
The pure dependency based is the reason why make is much better tool than say ant, nant, etc…
It’s great when properly written makefile completes in


APT-CACHE(8) APT APT-CACHE(8) NAME apt-cache - query the APT cache SYNOPSIS apt-cache [-agipns] [-o=config_string] [-c=config_file] {gencaches | showpkg pkg... | showsrc pkg... | stats | dump | dumpavail | unmet | search regex... | show pkg [{=pkg_version_number | /target_release}]... | depends pkg [{=pkg_version_number | /target_release}]... | rdepends pkg [{=pkg_version_number | /target_release}]... | pkgnames [prefix] | dotty pkg [{=pkg_version_number | /target_release}]... | xvcg pkg [{=pkg_version_number | /target_release}]... | policy [pkg...] | madison pkg... | {-v | --version} | {-h | --help}} DESCRIPTION apt-cache performs a variety of operations on APT's package cache. apt-cache does not manipulate the state of the system but does provide operations to search and generate interesting output from the package metadata. Unless the -h, or --help option is given, one of the commands below must be present. gencaches gencaches creates APT's package cache. This is done implicitly by all commands needing this cache if it is missing or outdated. showpkg pkg... showpkg displays information about the packages listed on the command line. Remaining arguments are package names. The available versions and reverse dependencies of each package listed are listed, as well as forward dependencies for each version. Forward (normal) dependencies are those packages upon which the package in question depends; reverse dependencies are those packages that depend upon the package in question. Thus, forward dependencies must be satisfied for a package, but reverse dependencies need not be. For instance, apt-cache showpkg libreadline2 would produce output similar to the following: Package: libreadline2 Versions: 2.1-12(/var/state/apt/lists/foo_Packages), Reverse Depends: libreadlineg2,libreadline2 libreadline2-altdev,libreadline2 Dependencies: 2.1-12 - libc5 (2 5.4.0-0) ncurses3.0 (0 (null)) Provides: 2.1-12 - Reverse Provides: Thus it may be seen that libreadline2, version 2.1-12, depends on libc5 and ncurses3.0 which must be installed for libreadline2 to work. In turn, libreadlineg2 and libreadline2-altdev depend on libreadline2. If libreadline2 is installed, libc5 and ncurses3.0 (and ldso) must also be installed; libreadlineg2 and libreadline2-altdev do not have to be installed. For the specific meaning of the remainder of the output it is best to consult the apt source code. stats stats displays some statistics about the cache. No further arguments are expected. Statistics reported are: · Total package names is the number of package names found in the cache. · Normal packages is the number of regular, ordinary package names; these are packages that bear a one-to-one correspondence between their names and the names used by other packages for them in dependencies. The majority of packages fall into this category. · Pure virtual packages is the number of packages that exist only as a virtual package name; that is, packages only "provide" the virtual package name, and no package actually uses the name. For instance, "mail-transport-agent" in the Debian system is a pure virtual package; several packages provide "mail-transport-agent", but there is no package named "mail-transport-agent". · Single virtual packages is the number of packages with only one package providing a particular virtual package. For example, in the Debian system, "X11-text-viewer" is a virtual package, but only one package, xless, provides "X11-text-viewer". · Mixed virtual packages is the number of packages that either provide a particular virtual package or have the virtual package name as the package name. For instance, in the Debian system, "debconf" is both an actual package, and provided by the debconf-tiny package. · Missing is the number of package names that were referenced in a dependency but were not provided by any package. Missing packages may be an evidence if a full distribution is not accessed, or if a package (real or virtual) has been dropped from the distribution. Usually they are referenced from Conflicts or Breaks statements. · Total distinct versions is the number of package versions found in the cache; this value is therefore at least equal to the number of total package names. If more than one distribution is being accessed (for instance, "stable" and "unstable"), this value can be considerably larger than the number of total package names. · Total dependencies is the number of dependency relationships claimed by all of the packages in the cache. showsrc pkg... showsrc displays all the source package records that match the given package names. All versions are shown, as well as all records that declare the name to be a binary package. dump dump shows a short listing of every package in the cache. It is primarily for debugging. dumpavail dumpavail prints out an available list to stdout. This is suitable for use with dpkg(1) and is used by the dselect(1) method. unmet unmet displays a summary of all unmet dependencies in the package cache. show pkg... show performs a function similar to dpkg --print-avail; it displays the package records for the named packages. search regex... search performs a full text search on all available package lists for the POSIX regex pattern given, see regex(7). It searches the package names and the descriptions for an occurrence of the regular expression and prints out the package name and the short description, including virtual package names. If --full is given then output identical to show is produced for each matched package, and if --names-only is given then the long description is not searched, only the package name is. Separate arguments can be used to specify multiple search patterns that are and'ed together. depends pkg... depends shows a listing of each dependency a package has and all the possible other packages that can fulfill that dependency. rdepends pkg... rdepends shows a listing of each reverse dependency a package has. pkgnames [prefix] This command prints the name of each package APT knows. The optional argument is a prefix match to filter the name list. The output is suitable for use in a shell tab complete function and the output is generated extremely quickly. This command is best used with the --generate option. Note that a package which APT knows of is not necessarily available to download, installable or installed, e.g. virtual packages are also listed in the generated list. dotty pkg... dotty takes a list of packages on the command line and generates output suitable for use by dotty from the GraphViz[1] package. The result will be a set of nodes and edges representing the relationships between the packages. By default the given packages will trace out all dependent packages; this can produce a very large graph. To limit the output to only the packages listed on the command line, set the APT::Cache::GivenOnly option. The resulting nodes will have several shapes; normal packages are boxes, pure virtual packages are triangles, mixed virtual packages are diamonds, missing packages are hexagons. Orange boxes mean recursion was stopped (leaf packages), blue lines are pre-depends, green lines are conflicts. Caution, dotty cannot graph larger sets of packages. xvcg pkg... The same as dotty, only for xvcg from the VCG tool[2]. policy [pkg...] policy is meant to help debug issues relating to the preferences file. With no arguments it will print out the priorities of each source. Otherwise it prints out detailed information about the priority selection of the named package. madison pkg... apt-cache's madison command attempts to mimic the output format and a subset of the functionality of the Debian archive management tool, madison. It displays available versions of a package in a tabular format. Unlike the original madison, it can only display information for the architecture for which APT has retrieved package lists (APT::Architecture). OPTIONS All command line options may be set using the configuration file, the descriptions indicate the configuration option to set. For boolean options you can override the config file by using something like -f-,--no-f, -f=no or several other variations. -p, --pkg-cache Select the file to store the package cache. The package cache is the primary cache used by all operations. Configuration Item: Dir::Cache::pkgcache. -s, --src-cache Select the file to store the source cache. The source is used only by gencaches and it stores a parsed version of the package information from remote sources. When building the package cache the source cache is used to avoid reparsing all of the package files. Configuration Item: Dir::Cache::srcpkgcache. -q, --quiet Quiet; produces output suitable for logging, omitting progress indicators. More q's will produce more quietness up to a maximum of 2. You can also use -q=# to set the quietness level, overriding the configuration file. Configuration Item: quiet. -i, --important Print only important dependencies; for use with unmet and depends. Causes only Depends and Pre-Depends relations to be printed. Configuration Item: APT::Cache::Important. --no-pre-depends, --no-depends, --no-recommends, --no-suggests, --no-conflicts, --no-breaks, --no-replaces, --no-enhances Per default the depends and rdepends print all dependencies. This can be tweaked with these flags which will omit the specified dependency type. Configuration Item: APT::Cache::ShowDependencyType e.g. APT::Cache::ShowRecommends. -f, --full Print full package records when searching. Configuration Item: APT::Cache::ShowFull. -a, --all-versions Print full records for all available versions. This is the default; to turn it off, use --no-all-versions. If --no-all-versions is specified, only the candidate version will be displayed (the one which would be selected for installation). This option is only applicable to the show command. Configuration Item: APT::Cache::AllVersions. -g, --generate Perform automatic package cache regeneration, rather than use the cache as it is. This is the default; to turn it off, use --no-generate. Configuration Item: APT::Cache::Generate. --names-only, -n Only search on the package names, not the long descriptions. Configuration Item: APT::Cache::NamesOnly. --all-names Make pkgnames print all names, including virtual packages and missing dependencies. Configuration Item: APT::Cache::AllNames. --recurse Make depends and rdepends recursive so that all packages mentioned are printed once. Configuration Item: APT::Cache::RecurseDepends. --installed Limit the output of depends and rdepends to packages which are currently installed. Configuration Item: APT::Cache::Installed. -h, --help Show a short usage summary. -v, --version Show the program version. -c, --config-file Configuration File; Specify a configuration file to use. The program will read the default configuration file and then this configuration file. If configuration settings need to be set before the default configuration files are parsed specify a file with the APT_CONFIG environment variable. See apt.conf(5) for syntax information. -o, --option Set a Configuration Option; This will set an arbitrary configuration option. The syntax is -o Foo::Bar=bar. -o and --option can be used multiple times to set different options. FILES /etc/apt/sources.list Locations to fetch packages from. Configuration Item: Dir::Etc::SourceList. /etc/apt/sources.list.d/ File fragments for locations to fetch packages from. Configuration Item: Dir::Etc::SourceParts. /var/lib/apt/lists/ Storage area for state information for each package resource specified in sources.list(5) Configuration Item: Dir::State::Lists. /var/lib/apt/lists/partial/ Storage area for state information in transit. Configuration Item: Dir::State::Lists (partial will be implicitly appended) SEE ALSO apt.conf(5), sources.list(5), apt-get(8) DIAGNOSTICS apt-cache returns zero on normal operation, decimal 100 on error. BUGS APT bug page[3]. If you wish to report a bug in APT, please see /usr/share/doc/debian/bug-reporting.txt or the reportbug(1) command. AUTHORS Jason Gunthorpe APT team NOTES 1. GraphViz http://www.research.att.com/sw/tools/graphviz/ 2. VCG tool http://rw4.cs.uni-sb.de/users/sander/html/gsvcg1.html 3. APT bug page http://bugs.debian.org/src:apt APT <IP_ADDRESS> 09 June 2012 APT-CACHE(8)


@* * Copyright 2019 HM Revenue & Customs * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. *@ @import forms.Form2 @import include._ @import include.forms2._ @import config.ApplicationConfig @(f: Form2[_], edit: Boolean, activityValues: Seq[String], existing: Seq[String])(implicit request: Request[_],m:Messages, lang: Lang) @header = { @components.back_link() @errorSummary(f) @heading("businessmatching.updateservice.selectactivities.heading", "summary.updateservice") } @main( title = Messages("businessmatching.updateservice.selectactivities.title") + " - " + Messages("summary.updateservice"), heading = header ) { @current_business_types(existing.toSet)
@Messages("businessmatching.updateservice.selectactivities.hint")
@form(f, controllers.businessmatching.updateservice.add.routes.SelectBusinessTypeController.post(edit)) {


decoders¶
This package contains various decoder. A Decoder typically takes representation and produces data.
decoder¶
-
class
decoders.decoder.
Decoder
(params, model, name='decoder', mode='train')[source]¶ Bases:
object
Abstract class from which all decoders must inherit.
-
__init__
(params, model, name='decoder', mode='train')[source]¶ Decoder constructor. Note that decoder constructors should not modify TensorFlow graph, all graph construction should happen in the
self._decode()
method.Parameters: - params (dict) – parameters describing the decoder.
All supported parameters are listed in
get_required_params()
,get_optional_params()
functions. - model (instance of a class derived from
Model
) – parent model that created this decoder. Could be None if no model access is required for the use case. - name (str) – name for decoder variable scope.
- mode (str) – mode decoder is going to be run in. Could be “train”, “eval” or “infer”.
Config parameters:
- initializer — any valid TensorFlow initializer. If no initializer is provided, model initializer will be used.
- initializer_params (dict) — dictionary that will be passed to
initializer
__init__
method. - regularizer — and valid TensorFlow regularizer. If no regularizer is provided, model regularizer will be used.
- regularizer_params (dict) — dictionary that will be passed to
regularizer
__init__
method. - dtype — model dtype. Could be either
tf.float16
,tf.float32
or “mixed”. For details see mixed precision training section in docs. If no dtype is provided, model dtype will be used.
- params (dict) – parameters describing the decoder.
All supported parameters are listed in
-
_cast_types
(input_dict)[source]¶ This function performs automatic cast of all inputs to decoder dtype.
Parameters: input_dict (dict) – dictionary passed to self._decode()
method.Returns: same as input_dict, but with all Tensors cast to decoder dtype. Return type: dict
-
_decode
(input_dict)[source]¶ This is the main function which should construct decoder graph. Typically, decoder will take hidden representation from encoder as an input and produce some output sequence as an output.
Parameters: input_dict (dict) – dictionary containing decoder inputs. If the decoder is used with
models.encoder_decoder
class,input_dict
will have the following content:{ "encoder_output": dictionary returned from encoder.encode() method "target_tensors": data_layer.input_tensors['target_tensors'] }
Returns: dictionary of decoder outputs. Typically this will be just: { "logits": logits that will be passed to Loss "outputs": list with actual decoded outputs, e.g. characters instead of logits }
Return type: dict
-
decode
(input_dict)[source]¶ Wrapper around
self._decode()
method. Here name, initializer and dtype are set in the variable scope and thenself._decode()
method is called.Parameters: input_dict (dict) – see self._decode()
docs.Returns: see self._decode()
docs.
-
static
get_optional_params
()[source]¶ Static method with description of optional parameters.
Returns: Dictionary containing all the parameters that can be included into the params
parameter of the class__init__()
method.Return type: dict
-
static
get_required_params
()[source]¶ Static method with description of required parameters.
Returns: Dictionary containing all the parameters that have to be included into the params
parameter of the class__init__()
method.Return type: dict
-
mode
¶ Mode decoder is run in.
-
name
¶ Decoder name.
-
params
¶ Parameters used to construct the decoder (dictionary)
-
fc_decoders¶
This module defines various fully-connected decoders (consisting of one fully connected layer).
These classes are usually used for models that are not really sequence-to-sequence and thus should be artificially split into encoder and decoder by cutting, for example, on the last fully-connected layer.
-
class
decoders.fc_decoders.
FullyConnectedCTCDecoder
(params, model, name='fully_connected_ctc_decoder', mode='train')[source]¶ Bases:
decoders.fc_decoders.FullyConnectedTimeDecoder
Fully connected time decoder that provides a CTC-based text generation (either with or without language model). If language model is not used,
tf.nn.ctc_greedy_decoder
will be used as text generation method.-
__init__
(params, model, name='fully_connected_ctc_decoder', mode='train')[source]¶ Fully connected CTC decoder constructor.
See parent class for arguments description.
Config parameters:
- use_language_model (bool) — whether to use language model for output text generation. If False, other config parameters are not used.
- decoder_library_path (string) — path to the ctc decoder with language model library.
- lm_binary_path (string) — path to the language model file.
- lm_trie_path (string) — path to the language model trie file.
- alphabet_config_path (string) — path to the alphabet file.
- beam_width (int) — beam width for beam search.
- lm_weight (float) — weight that is assigned to language model probabilities.
- word_count_weight (float) — weight that is assigned to the word count.
- valid_word_count_weight (float) — weight that is assigned to the valid word count, i.e. words that exist in language model dictionary.
-
static
get_optional_params
()[source]¶ Static method with description of optional parameters.
Returns: Dictionary containing all the parameters that can be included into the params
parameter of the class__init__()
method.Return type: dict
-
static
get_required_params
()[source]¶ Static method with description of required parameters.
Returns: Dictionary containing all the parameters that have to be included into the params
parameter of the class__init__()
method.Return type: dict
-
-
class
decoders.fc_decoders.
FullyConnectedDecoder
(params, model, name='fully_connected_decoder', mode='train')[source]¶ Bases:
decoders.decoder.Decoder
Simple decoder consisting of one fully-connected layer.
-
__init__
(params, model, name='fully_connected_decoder', mode='train')[source]¶ Fully connected decoder constructor.
See parent class for arguments description.
Config parameters:
- output_dim (int) — output dimension.
-
_decode
(input_dict)[source]¶ This method performs linear transformation of input.
Parameters: input_dict (dict) – input dictionary that has to contain the following fields:
input_dict = { 'encoder_output': { 'outputs': output of encoder (shape=[batch_size, num_features]) } }
Returns: dictionary with the following tensors: { 'logits': logits with the shape=[batch_size, output_dim] 'outputs': [logits] (same as logits but wrapped in list) }
Return type: dict
-
static
get_required_params
()[source]¶ Static method with description of required parameters.
Returns: Dictionary containing all the parameters that have to be included into the params
parameter of the class__init__()
method.Return type: dict
-
-
class
decoders.fc_decoders.
FullyConnectedTimeDecoder
(params, model, name='fully_connected_time_decoder', mode='train')[source]¶ Bases:
decoders.decoder.Decoder
Fully connected decoder that operates on inputs with time dimension. That is, input shape should be
[batch size, time length, num features]
.-
__init__
(params, model, name='fully_connected_time_decoder', mode='train')[source]¶ Fully connected time decoder constructor.
See parent class for arguments description.
Config parameters:
- tgt_vocab_size (int) — target vocabulary size, i.e. number of output features.
- logits_to_outputs_func — function that maps produced logits to decoder outputs, i.e. actual text sequences.
-
_decode
(input_dict)[source]¶ Creates TensorFlow graph for fully connected time decoder.
Parameters: input_dict (dict) – input dictionary that has to contain the following fields:
input_dict = { 'encoder_output': { "outputs": tensor with shape [batch_size, time length, hidden dim] "src_length": tensor with shape [batch_size] } }
Returns: dictionary with the following tensors: { 'logits': logits with the shape=[time length, batch_size, tgt_vocab_size] 'outputs': logits_to_outputs_func(logits, input_dict) }
Return type: dict
-
static
get_optional_params
()[source]¶ Static method with description of optional parameters.
Returns: Dictionary containing all the parameters that can be included into the params
parameter of the class__init__()
method.Return type: dict
-
static
get_required_params
()[source]¶ Static method with description of required parameters.
Returns: Dictionary containing all the parameters that have to be included into the params
parameter of the class__init__()
method.Return type: dict
-
rnn_decoders¶
RNN-based decoders.
-
class
decoders.rnn_decoders.
BeamSearchRNNDecoderWithAttention
(params, model, name='rnn_decoder_with_attention', mode='train')[source]¶ Bases:
decoders.rnn_decoders.RNNDecoderWithAttention
Beam search version of RNN-based decoder with attention. Can be used only during Inference (mode=infer)
-
__init__
(params, model, name='rnn_decoder_with_attention', mode='train')[source]¶ Initializes beam search decoder.
Parameters: params (dict) – dictionary with decoder parameters Config parameters:
- batch_size — batch size
- GO_SYMBOL — GO symbol id, must be the same as used in data layer
- END_SYMBOL — END symbol id, must be the same as used in data layer
- tgt_vocab_size — vocabulary size of target
- tgt_emb_size — embedding to use
- decoder_cell_units — number of units in RNN
- decoder_cell_type — RNN type: lstm, gru, glstm, etc.
- decoder_dp_input_keep_prob —
- decoder_dp_output_keep_prob —
- decoder_use_skip_connections — use residual connections or not
- attention_type — bahdanau, luong, gnmt, gnmt_v2
- bahdanau_normalize — (optional)
- luong_scale — (optional)
- mode — train or infer
… add any cell-specific parameters here as well
-
_decode
(input_dict)[source]¶ Decodes representation into data.
Parameters: input_dict (dict) – Python dictionary with inputs to decoder - Must define:
- src_inputs - decoder input Tensor of shape [batch_size, time, dim]
- or [time, batch_size, dim]
- src_lengths - decoder input lengths Tensor of shape [batch_size]
Does not need tgt_inputs and tgt_lengths
Returns: a Python dictionary with: * final_outputs - tensor of shape [batch_size, time, dim] or [time, batch_size, dim]- final_state - tensor with decoder final state
- final_sequence_lengths - tensor of shape [batch_size, time] or
- [time, batch_size]
Return type: dict
-
static
get_optional_params
()[source]¶ Static method with description of optional parameters.
Returns: Dictionary containing all the parameters that can be included into the params
parameter of the class__init__()
method.Return type: dict
-
-
class
decoders.rnn_decoders.
RNNDecoderWithAttention
(params, model, name='rnn_decoder_with_attention', mode='train')[source]¶ Bases:
decoders.decoder.Decoder
Typical RNN decoder with attention mechanism.
-
__init__
(params, model, name='rnn_decoder_with_attention', mode='train')[source]¶ Initializes RNN decoder with embedding.
See parent class for arguments description.
Config parameters:
- batch_size (int) — batch size.
- GO_SYMBOL (int) — GO symbol id, must be the same as used in data layer.
- END_SYMBOL (int) — END symbol id, must be the same as used in data layer.
- tgt_emb_size (int) — embedding size to use.
- core_cell_params (dict) - parameters for RNN class
- core_cell (string) - RNN class.
- decoder_dp_input_keep_prob (float) - dropout input keep probability.
- decoder_dp_output_keep_prob (float) - dropout output keep probability.
- decoder_use_skip_connections (bool) - use residual connections or not.
- attention_type (string) - bahdanau, luong, gnmt or gnmt_v2.
- bahdanau_normalize (bool, optional) - whether to use normalization in bahdanau attention.
- luong_scale (bool, optional) - whether to use scale in luong attention
- … add any cell-specific parameters here as well.
-
_build_attention
(encoder_outputs, encoder_sequence_length)[source]¶ Builds Attention part of the graph. Currently supports “bahdanau” and “luong”.
-
_decode
(input_dict)[source]¶ Decodes representation into data.
Parameters: input_dict (dict) – Python dictionary with inputs to decoder. Config parameters:
- src_inputs — Decoder input Tensor of shape [batch_size, time, dim] or [time, batch_size, dim]
- src_lengths — Decoder input lengths Tensor of shape [batch_size]
- tgt_inputs — Only during training. labels Tensor of the shape [batch_size, time] or [time, batch_size].
- tgt_lengths — Only during training. labels lengths Tensor of the shape [batch_size].
Returns: Python dictionary with: * final_outputs - tensor of shape [batch_size, time, dim] or [time, batch_size, dim]- final_state - tensor with decoder final state
- final_sequence_lengths - tensor of shape [batch_size, time]
- or [time, batch_size]
Return type: dict
-
static
get_optional_params
()[source]¶ Static method with description of optional parameters.
Returns: Dictionary containing all the parameters that can be included into the params
parameter of the class__init__()
method.Return type: dict
-
static
get_required_params
()[source]¶ Static method with description of required parameters.
Returns: Dictionary containing all the parameters that have to be included into the params
parameter of the class__init__()
method.Return type: dict
-
transformer_decoder¶
-
class
decoders.transformer_decoder.
TransformerDecoder
(params, model, name='transformer_decoder', mode='train')[source]¶ Bases:
decoders.decoder.Decoder
-
_get_symbols_to_logits_fn
(max_decode_length)[source]¶ Returns a decoding function that calculates logits of the next tokens.
-
decode_pass
(targets, encoder_outputs, inputs_attention_bias)[source]¶ Generate logits for each value in the target sequence.
Parameters: - targets – target values for the output sequence. int tensor with shape [batch_size, target_length]
- encoder_outputs – continuous representation of input sequence. float tensor with shape [batch_size, input_length, hidden_size]
- inputs_attention_bias – float tensor with shape [batch_size, 1, 1, input_length]
Returns: float32 tensor with shape [batch_size, target_length, vocab_size]
-
static
get_optional_params
()[source]¶ Static method with description of optional parameters.
Returns: Dictionary containing all the parameters that can be included into the params
parameter of the class__init__()
method.Return type: dict
-
convs2s_decoder¶
-
class
decoders.convs2s_decoder.
ConvS2SDecoder
(params, model, name='convs2s_decoder', mode='train')[source]¶ Bases:
decoders.decoder.Decoder
-
_get_symbols_to_logits_fn
()[source]¶ Returns a decoding function that calculates logits of the next tokens.
-
decode_pass
(targets, encoder_outputs, encoder_outputs_b, inputs_attention_bias)[source]¶ Generate logits for each value in the target sequence.
Parameters: - targets – target values for the output sequence. int tensor with shape [batch_size, target_length]
- encoder_outputs – continuous representation of input sequence. float tensor with shape [batch_size, input_length, hidden_size] float tensor with shape [batch_size, input_length, hidden_size]
- encoder_outputs_b – continuous representation of input sequence which includes the source embeddings. float tensor with shape [batch_size, input_length, hidden_size]
- inputs_attention_bias – float tensor with shape [batch_size, 1, input_length]
Returns: float32 tensor with shape [batch_size, target_length, vocab_size]
-
static
get_optional_params
()[source]¶ Static method with description of optional parameters.
Returns: Dictionary containing all the parameters that can be included into the params
parameter of the class__init__()
method.Return type: dict
-
tacotron2_decoder¶
Tacotron2 decoder
-
class
decoders.tacotron2_decoder.
Prenet
(num_units, num_layers, activation_fn=None, dtype=None)[source]¶ Bases:
object
Fully connected prenet used in the decoder
-
__init__
(num_units, num_layers, activation_fn=None, dtype=None)[source]¶ Prenet initializer
Parameters: - num_units (int) – number of units in the fully connected layer
- num_layers (int) – number of fully connected layers
- activation_fn (callable) – any valid activation function
- dtype (dtype) – the data format for this layer
-
output_size
¶
-
-
class
decoders.tacotron2_decoder.
Tacotron2Decoder
(params, model, name='tacotron_2_decoder', mode='train')[source]¶ Bases:
decoders.decoder.Decoder
Tacotron 2 Decoder
-
__init__
(params, model, name='tacotron_2_decoder', mode='train')[source]¶ Tacotron-2 like decoder constructor. A lot of optional configurations are currently for testing. Not all configurations are supported. Use of thed efault config is reccommended.
See parent class for arguments description.
Config parameters:
attention_layer_size (int) — size of attention layer.
attention_type (string) — Determines whether attention mechanism to use, should be one of ‘bahdanau’, ‘location’, or None. Use of ‘location’-sensitive attention is strongly recommended.
bahdanau_normalize (bool) — Defaults to False.
decoder_cell_units (int) — dimension of decoder RNN cells.
decoder_layers (int) — number of decoder RNN layers to use.
decoder_cell_type (callable) — could be “lstm”, “gru”, “glstm”, or “slstm”. Currently, only ‘lstm’ has been tested. Defaults to ‘lstm’.
time_major (bool) — whether to output as time major or batch major. Default is False for batch major.
use_swap_memory (bool) — default is False.
enable_prenet (bool) — whether to use the fully-connected prenet in the decoder. Defaults to True
prenet_layers (int) — number of fully-connected layers to use. Defaults to 2.
prenet_units (int) — number of units in each layer. Defaults to 256.
prenet_activation (callable) — activation function to use for the prenet lyaers. Defaults to relu
enable_postnet (bool) — whether to use the convolutional postnet in the decoder. Defaults to True
postnet_conv_layers (bool) — list with the description of convolutional layers. Must be passed if postnet is enabled For example:
"postnet_conv_layers": [ { "kernel_size": [5], "stride": [1], "num_channels": 512, "padding": "SAME", "activation_fn": tf.nn.tanh }, { "kernel_size": [5], "stride": [1], "num_channels": 512, "padding": "SAME", "activation_fn": tf.nn.tanh }, { "kernel_size": [5], "stride": [1], "num_channels": 512, "padding": "SAME", "activation_fn": tf.nn.tanh }, { "kernel_size": [5], "stride": [1], "num_channels": 512, "padding": "SAME", "activation_fn": tf.nn.tanh }, { "kernel_size": [5], "stride": [1], "num_channels": 80, "padding": "SAME", "activation_fn": None } ]
postnet_bn_momentum (float) — momentum for batch norm. Defaults to 0.1.
postnet_bn_epsilon (float) — epsilon for batch norm. Defaults to 1e-5.
postnet_data_format (string) — could be either “channels_first” or “channels_last”. Defaults to “channels_last”.
postnet_keep_dropout_prob (float) — keep probability for dropout in the postnet conv layers. Default to 0.5.
mask_decoder_sequence (bool) — Defaults to True
attention_bias (bool) — Wether to use a bias term when calculating the attention. Only works for “location” attention. Defaults to False.
zoneout_prob (float) — zoneout probability. Defaults to 0.1
parallel_iterations (int) — Number of parallel_iterations for tf.while loop inside dynamic_decode. Defaults to 32.
-
_build_attention
(encoder_outputs, encoder_sequence_length, attention_bias)[source]¶ Builds Attention part of the graph. Currently supports “bahdanau”, and “location”
-
_decode
(input_dict)[source]¶ Decodes representation into data
Parameters: input_dict (dict) – Python dictionary with inputs to decoder. Must define:
- src_inputs - decoder input Tensor of shape [batch_size, time, dim] or [time, batch_size, dim]
- src_lengths - decoder input lengths Tensor of shape [batch_size]
- tgt_inputs - Only during training. labels Tensor of the shape [batch_size, time, num_features] or [time, batch_size, num_features]
- stop_token_inputs - Only during training. labels Tensor of the shape [batch_size, time, 1] or [time, batch_size, 1]
- tgt_lengths - Only during training. labels lengths Tensor of the shape [batch_size]
Returns: - A python dictionary containing:
- outputs - array containing:
- decoder_output - tensor of shape [batch_size, time, num_features] or [time, batch_size, num_features]. Spectrogram representation learned by the decoder rnn
- spectrogram_prediction - tensor of shape [batch_size, time, num_features] or [time, batch_size, num_features]. Spectrogram containing the residual corrections from the postnet if enabled
- alignments - tensor of shape [batch_size, time, memory_size] or [time, batch_size, memory_size]. The alignments learned by the attention layer
- stop_token_prediction - tensor of shape [batch_size, time, 1] or [time, batch_size, 1]. The stop token predictions
- final_sequence_lengths - tensor of shape [batch_size]
- stop_token_predictions - tensor of shape [batch_size, time, 1] or [time, batch_size, 1]. The stop token predictions for use inside the loss function.
Return type: dict
-
static
get_optional_params
()[source]¶ Static method with description of optional parameters.
Returns: Dictionary containing all the parameters that can be included into the params
parameter of the class__init__()
method.Return type: dict
-
static
get_required_params
()[source]¶ Static method with description of required parameters.
Returns: Dictionary containing all the parameters that have to be included into the params
parameter of the class__init__()
method.Return type: dict
-


|
xpcc
|
Basic Extended CAN2. More...
#include <driver/can/stm32/can_2.hpp>
Public Types | |
| enum | Mode : uint32_t { Normal, ListenOnly, LoopBack, ListenOnlyLoopBack } |
| Public Types inherited from xpcc::Can | |
| enum | Mode : uint8_t { Mode::Normal, Mode::ListenOnly, Mode::LoopBack, Mode::ListenOnlyLoopBack } |
| Possible modes of the CAN controller. More... | |
| enum | Bitrate : uint32_t { kBps10, kBps20, kBps50, kBps100, kBps125, kBps250, kBps500, MBps1 } |
| Supported CAN bitrates; maybe different on a per device basis. | |
| enum | BusState : uint8_t { BusState::Connected, BusState::ErrorWarning, BusState::ErrorPassive, Off } |
Static Public Member Functions | |
| template<class SystemClock , uint32_t bitrate = Bitrate::kBps125, uint16_t tolerance = Tolerance::OnePercent> | |
| static void | initialize (uint32_t interruptPriority, Mode startupMode=Mode::Normal, bool overwriteOnOverrun=true) |
| Enables the clock for the CAN controller and resets all settings. More... | |
| static void | setMode (Mode mode) |
| The the operating mode. More... | |
| static void | setAutomaticRetransmission (bool retransmission) |
| static bool | isMessageAvailable () |
| static bool | getMessage (can::Message &message) |
| static bool | isReadyToSend () |
| static bool | sendMessage (const can::Message &message) |
| static uint8_t | getReceiveErrorCounter () |
| Get Receive Error Counter. More... | |
| static uint8_t | getTransmitErrorCounter () |
| Get Transmit Error Counter. | |
| static BusState | getBusState () |
| static void | enableStatusChangeInterrupt (uint32_t interruptEnable, uint32_t interruptPriority) |
| Enable the error and status change interrupt. More... | |
| Static Public Member Functions inherited from xpcc::Can | |
| template<class SystemClock , uint32_t bitrate = Bitrate::kBps125, uint16_t tolerance = Tolerance::OnePercent> | |
| static void | initialize (Mode startupMode) |
| Initializes the hardware and sets the baudrate. More... | |
| static bool | isMessageAvailable () |
Returns true if a message can be retrieved by calling getMessage . | |
| static bool | getMessage (can::Message &message) |
| Returns true if a message was copied into the message buffer. | |
| static bool | isReadyToSend () |
| The CAN controller has a free slot to send a new message. More... | |
| static bool | sendMessage (const can::Message &message) |
| Send a message over the CAN. More... | |
| static uint8_t | getReceiveErrorCounter () |
| Get Receive Error Counter. | |
| static uint8_t | getTransmitErrorCounter () |
| Get Transmit Error Counter. | |
| static BusState | getBusState () |
| Static Public Member Functions inherited from xpcc::Peripheral | |
| template<uint32_t available, uint32_t requested, uint16_t tolerance> | |
| static void | assertBaudrateInTolerance () |
| Since baudrates are usually generated by prescaling a system clock, only several distinct values can be generated. More... | |
Static Public Attributes | |
| static const TypeId::Can2Rx | Rx |
| TypeId used to connect GPIO pins to this peripheral's rx. | |
| static const TypeId::Can2Tx | Tx |
| TypeId used to connect GPIO pins to this peripheral's tx. | |
The Basic Extended CAN peripheral, named bxCAN, interfaces the CAN network. It supports the CAN protocols version 2.0A and B. It has been designed to manage a high number of incoming messages efficiently with a minimum CPU load.
For connectivity line devices there are 28 filter banks, i=0 .. 27, in other devices there are 14 filter banks i = 0 ..13.
The 28 filter banks for the connectivity line devices are shared between CAN1 and CAN2.
You can set the buffer size using the tx_buffer
and rx_buffer
parameters.
|
inlinestatic |
| bitrate | CAN bitrate (defined in driver/connectivity/can/message.hpp) |
| interruptPriority | Interrupt vector priority (0=highest to 15=lowest) |
| overwriteOnOverrun | Once a receive FIFO is full the next incoming message will overwrite the previous one if true otherwise the incoming message will be discarded |
|
static |
Default after initialization is the normal mode.
|
inlinestatic |
In case of an error during reception, this counter is incremented by 1 or by 8 depending on the error condition as defined by the CAN standard. After every successful reception the counter is decremented by 1 or reset to 120 if its value was higher than 128. When the counter value exceeds 127, the CAN controller enters the error passive state.
|
static |
Can be generated by the following events:
You need to create you own interrupt handler for this interrupt. The interrupt handler has a fixed name:
| interruptEnable | Upper 24-bit of the CAN_IER register. E.g.:
|
| interruptPriority | Interrupt vector priority (0=highest to 15=lowest) |


WITNESS LIST Business & Commerce Committee March 20, 2001 - 9:00A SB 12 AGAINST: Knepp, Chris (Texas Employment Law Council), Austin, TX Pollard, Mike (Texas Association of Life and Health Insurers), Austin, TX Thompson, Jay (TACHI), Austin, TX ON: Drummond-Borg, MD, Margaret (T.D.H.), Austin, TX Epps, Phyllis Griffin (University of Houston Health Law and Policy Institute), Houston, TX SB 63 FOR: Borel, Dennis (Coalition of Texans with Disabilities), Austin, TX Schwartz, Jonas (Advocacy, Inc.), Austin, TX Registering, but not testifying: For: Keel, Lara Laneri (Texas Association of Business and Chambers of Commerce), Austin, TX On: Comer, Teresa (State Comptroller), Austin, TX SB 314 FOR: Rose, Harold L. (AARP), Austin, TX Schneider, Rob (Consumers Union), Austin, TX AGAINST: Carroll, B.F. Hank (Texas Cemeteries Association), Ft. Worth, TX Gonzales, Norman (Sea Side Memorial Park and Funeral Home), Corpus Christi, TX Hankins, Lamar (Funeral Consumers Alliance), San Marcos, TX Ramey, Cole (Restland Funeral Home, Inc.), Dallas, TX Sullivan, James L. (Self), Houston, TX ON: James, Randall S. (Texas Department of Banking), Austin, TX Registering, but not testifying: For: Bower, Bruce P. (Texas Senior Advocacy Coalition), Austin, TX Smith, Tom "Smitty" (Public Citizens Members), Austin, TX Against: Anderson, Kirk T. (Stewart Enterprises), Dallas, TX Claybar, W. Brown (Texas Funeral Directors Association), Orange, TX Clayton, John G. (South Park Cemetery/Anderson-Clayton Bros. F.H.), Houston, TX Dalton, Cecil E. (Dalton and Son Funeral Home), Lewisville, TX Driggers, Gregg (David Clayton and Sons Funeral Home and Little Bethel Memorial Park), Duncanville, TX Faram, Steven O. (Laurel Land of Ft. Worth Funeral Home and Cemetery), Ft. Worth, TX Fisher, Hortense (Cook-Walden), Austin, TX Hughes, Caressa (Funeral and Cemetery Business), Houston, TX Manceaux, Chris (Laurel Land Funeral Home and Cemetery), Dallas, TX Martin, William A. (Martin Funeral Homes Inc.), El Paso, TX Penn, Brett (Stewart Evt. - Metrocrest F.H.), Carrollton, TX Perez, Daryle (Emerald Hills Funeral Home and Memorial Park), Kennedale, TX Rouse, Bob (Laurel Land Funeral Home and Memorial Park), Dallas, TX Schoonmaker, Greg (Bluebonnet Hills Funeral Home and Memorial Park), Colleyville, TX Shotwell, Ray (Brookside Funeral Home), Houston, TX Simchik, David (Funeral Directors), San Marcos, TX Snider, John A. (Funeral Director), Crosby, TX Vandiver, Bert (Brookview and Gatesville Funeral Homes) Vandiver, Jeanette (Funeral Homes), Waco, TX Walden, Sr., Charles (Funeral Profession - Cook-Walden F.H.), Austin, TX Wells, Joe K. (Cook-Walden), Austin, TX Wilcox, Bill B. (Clements-Wilcox Funeral Homes), Burnet, TX Willoughby, Mark (Forethought Federal Savings Bank - Houston, Tx.), Batesville, IN On: Jobe, Everette (Texas Department of Banking), Austin, TX Mazur, Jeremy (Sunset Commission), Austin, TX McKay, Ginny (Sunset Commission), Austin, TX Reese, Russell S. (Texas Department of Banking), Austin, TX SB 326 Registering, but not testifying: For: Gutierrez, Hector (City of El Paso), Austin, TX Martinez, Mario A. (Texas Border Infrastructure, Inter-Agency Group-Brownsville), Austin, TX On: Moseley, Jeff (Texas Department of Economic Development), Austin, TX Wrenn, Melvin G. (TDED), Austin, TX SB 424 FOR: Comacho, Jose E. (Texas Association of Community Health Centers, Inc.), Austin, TX Registering, but not testifying: On: Devin, Pat (Health and Human Services Commission), Austin, TX Moreno, Arthur T. (Texas Health Department), Austin, TX SB 471 FOR: White, Bill (Cash America International), Ft. Worth, TX AGAINST: Schneider, Rob (Consumers Union), Austin, TX ON: Munz, Kevin (Mr Money Holdings, Inc), Houston, TX Pettijohn, Leslie (Consumer Credit Commissioner), Austin, TX Registering, but not testifying: Against: Ewart, Ella (Texas Alliance for Human Needs), Austin, TX Murphy, Thomas E. (Texas Deterred Depositor Association), Killeen, TX Rose, Harold L. (AARP), Austin, TX Smith, Tom "Smitty" (Public Citizens Member), Austin, TX On: Abbott, Ronald (Peoples National Bank), Paris, TX Norrington, Eric (Ace Cash Express, Inc.), Dallas, TX SB 550 FOR: Kowalski, Tom (Texas Healthcare and Bioscience Institute), Austin, TX Stout, Bob (The Woodlands Operating Co. L.P.), The Woodlands, TX Registering, but not testifying: For: Loeffler, Lance (Introgen Therapeutics, Inc.), Austin, TX On: Guckian, Dr. James Vice Chancellor for Health Affairs (University of Texas System), Austin, TX SB 564 FOR: Pospisil, Scott (Texas Payphone Association), Austin, TX ON: Whittington, Pam (Public Utility Commission), Austin, TX Registering, but not testifying: For: McFarlin, Don (Southwestern Bell Telephone), Austin, TX SB 578 Registering, but not testifying: For: Hinkle, Ron (Verizon Wireless), Austin, TX Ratliff, Thomas (AT&T Wireless, Voicestream Wireless, Western Wireless), Austin, TX On: deNoyelles, John 9-1-1 Commissioner (Commission on State Emergency Communications), Tyler, TX Collins, Clay Deputy Director/Finance Officer (Capital Area Planning Council), Austin, TX Spence, Carry F. (Commissioin on State Emergency Communications), Austin, TX Voights, Betty (Capital Area Planning Council), Austin, TX SB 601 FOR: Adamek, Thomas J. (Stonehenge Capital Corp.), Baton Rouge, LA Dooley, David M. (Seasafe/Small Business), Lafayette, LA Leblanc, Gordon (Stonehenge Capital Corp.), Baton Rouge, LA Sisung, Larry (Sisung Capital), New Orleans, LA Thomas, Phil (Growth Capital Alliance), Alexandria, VA Registering, but not testifying: For: Hinojosa, Walter (Texas AFL-CIO), Austin, TX Johnson, Michael T. (Advantage Capital Partners), New Orleans, LA SB 604 Registering, but not testifying: On: Brady, Kevin (Texas Department of Insurance), Austin, TX Fleming, John C. (Center for Public Policy Dispute Resolution), Austin, TX SB 624 FOR: Beachley, Pam (Self), Austin, TX Korioth, Tony (TML-IRP), Austin, TX Levy, Rick (Texas AFL-CIO), Austin, TX AGAINST: Brewer, Travis R. (HCA-Columbia, Texas Association Residential Care Communities), Austin, TX Durrett, Larry K. (Self Employed- Taco Bell Restraunt), Jacksonville, TX Jackson, Richie (Texas Restaurant Association), Austin, TX Minick, Bill (Partner Source Inc.), Dallas, TX Rich, Sid (Texas Risk Retention Association), Austin, TX Smith, David (Tricon Restaurants (KFC, Taco Bell, Pizza Hut)), Dallas, TX ON: Bent, Steve (TXANS), Austin, TX McAnally, Scott (Research and Oversight Council on Workers' Compensation), Austin, TX Registering, but not testifying: For: Cobb, Ron (American Insurance Association), Austin, TX Freeman, Harold (Texas Medical Association), Austin, TX Thompson, Jay (AFACT), Austin, TX Woods, Joe (Alliance of American Insurers), Austin, TX Against: DuBois, Doug (Texas Petroleum Marketers and C-Store Association), Austin, TX Evans, Richard (Texas Association of Business and Chambers of Commerce), Austin, TX Green, Jim (Texas Association of Business and Chambers of Commerce), Hurst, TX Moore, Mickey (Texas Retailers Association), Austin, TX SB 804 Registering, but not testifying: For: Pollard, Mike (Texas Association of Life and Health Insurers), Austin, TX Rummel, Leah (Texas Association of Health Plans), Austin, TX SB 970 ON: Duncan, David Director Govt. Relations (Texas Workforce Commission), Austin, TX SB 1618 FOR: Kendrick, Gardner S. (San Miguel Electric Cooperative, Inc), San Antonio, TX AGAINST: Davie, Maxie (North American Coal Co.), Ft. Worth, TX Registering, but not testifying: For: Kamm, Bob (Travis County Commissioners Court), Austin, TX Williams, Mike (Texas Electric Cooperatives), Austin, TX


As described in Section Problems with Code Movement and Register Optimization , a dummy call may be necessary to tell the compiler that registers are to be flushed for a given buffer or that accesses to a buffer may not be moved across a given point in the execution sequence. Only a Fortran binding exists for this call.
| MPI_F_SYNC_REG(buf) | |
| INOUT buf | initial address of buffer (choice) |
This routine has no executable statements. It must be compiled in the MPI library in such a manner that a Fortran compiler cannot detect in the module that the routine has an empty body. It is used only to force the compiler to flush a cached register value of a variable or buffer back to memory (when necessary), or to invalidate the register value.
Rationale.
This function is not available in other languages
because it would not be useful.
This routine has no ierror return argument because
there is no operation that can fail.
( End of rationale.)
Advice
to implementors.
This routine can be bound to a C routine to minimize
the risk that the Fortran compiler can learn that this routine is empty
(and that the call to this routine can be removed
as part of an optimization).
However, it is explicitly allowed to implement this routine within the
mpi_f08 module according to the definition
for the mpi module or mpif.h to circumvent
the overhead of building the internal dope vector to handle
the assumed-type, assumed-rank argument.
( End of advice to implementors.)
Rationale.
This routine is not defined with TYPE(*), DIMENSION(*),
i.e., assumed size instead of assumed rank, because this
would restrict the usability to ``simply contiguous'' arrays
and would require overloading with another interface for
scalar arguments.
( End of rationale.)
Advice to users.
If only a part of an array (e.g., defined by a subscript triplet)
is used in a nonblocking routine,
it is recommended to pass the whole array to MPI_F_SYNC_REG
anyway to minimize the overhead of this no-operation call.
Note that this routine need not be called
if MPI_ASYNC_PROTECTS_NONBLOCKING is .TRUE. and
the application fully uses the facilities of ASYNCHRONOUS arrays.
( End of advice to users.)


Principality of Monaco issues weather information via Naya Maritime Communications - see www.naya.mc for full details.
A good continuous service for the Port Camargue to St Raphael area is on Channel 63. This is CROSSMED and the broadcast is in French but read very clearly and slowly with impeccable diction.
For links to free global weather information, forecast services and extreme weather information see the Noonsite Weather Page.
* indicates port of entry


Handle controls that have encoded characters in their text like » (»)
For this control the name should become LinkWith and the special character must be left-out Link with » Link with & extra whitespaces a text that is longer than the maximum length for identifiers<PHONE_NUMBER>123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890<PHONE_NUMBER>123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890 1234 starting with a number is not supported for identifiers


I was born in Memphis, Tn to a family of Christians. While I was raised within a christian home; I, myself was never one to follow religious dogma. Continued


Standard Books:
Free:
Borrowed:
VIP Books:
Free:
Borrowed:
Add Standard Book
Add VIP Book
Borrow Standard Book
Borrow VIP Book


{{site.user_description}}
I am fluent in Java, C/C++, Python, Kotlin and Bash programming. Through the co-op program at University Waterloo, I am able to apply knowledge such as programming languages learned in class in a professional setting.
Tools and IDEs such as Git, Vim, Android Studio and CLion have been helpful to me since day one. I find that these tools (and many more!) make me more productive and enjoy programming even more.
At my last co-op, I gained valuable experience in the tech industry by working with a team of experienced mobile developers on building and adding to a published native mobile application.


xANNA authenticity of artifacts published by xANNA |
Most artifacts published by xANNA in the registry have associated checksums to insure that when downloaded or passed around, nothing has been altered. These checksums are easy to check (see below). Artifacts that already have integrated integrity and authentication information (e.g. PKI certificates) may not be signed directly by the xANNA registrar.
Artifacts that contain or represent the assignment of a name or number are signed by at least one xANNA registrar. The signature is a promise that the artifact is a proper part of the registry. It conforms to the assignment guidelines and should not be in conflict with other registrations. It has passed through the hands of a registrar.
PKI root certificates are signed. Certificates issued from a CA root need only the signing embedded in the certificate chain.
The signature is not a guarantee of quality or the absence of errors, although we try our best to insure quality prior to signature.
Signed artifacts can not be changed. They can only be superseded by later versions or through deprecation/obsolescence/revocation. This process insures name and number allocations are never reused for some other purpose (which can create confusion and ambiguity).
The use of altered copies of signed artifacts means that xANNA can not vouch for the lack of conflicts with other names and numbers.
Checking the authenticity of artifacts is more complicated than checking integrity. Note that authenticity checking automatically verifies integrity. The procedure is covered below.
Registrar public keys are provided on this repository in the xANNA_KEYS file. However, obtaining them directly from here does not provide much security. If you wish to obtain the keys through another channel, please contract the registrar.
pub 4096R/6A5F408B 2018-12-24 uid Robert Hyerle (ranger6<EMAIL_ADDRESS>The procedures are modeled after those used by the Apache Software Foundation; in particular those used for Ant and Ivy.
A published artifact (a file) has one or more message digests associated with it. The digest is contained in a file with a name derived from the name of the artifact and the message digest algorithm. These files are normally placed in the same directory.
If the file is signed by a xANNA registrar, there will be an associated (detached) signature file with a name composed of the artifact file name and the ".asc" suffix.
For example, consider a text file named artifact.txt
. One
will find the following files:
$ ls -g total 32 -rw-r--r-- 1 staff 44 Dec 25 16:10 artifact.txt -rw-r--r-- 1 staff 256 Dec 25 17:10 artifact.txt.asc -rw-r--r-- 1 staff 63 Dec 25 17:04 artifact.txt.md5 -rw-r--r-- 1 staff 100 Dec 25 17:04 artifact.txt.sha256 $
One can generate and view the saved message digests manually and compare them:
$ gpg --print-md sha256 artifact.txt artifact.txt: C03905FC DAB29751 3A620EC8 1ED46CA4 4DDB62D4 1CBBD83E B4A5A359 2BE26A69 $ cat artifact.txt.sha256 artifact.txt: C03905FC DAB29751 3A620EC8 1ED46CA4 4DDB62D4 1CBBD83E B4A5A359 2BE26A69 $
This works in a similar manner for the MD5 digests.
To authenticate (check the signature of the registrars), one must first have the registrars' public keys. These keys should be imported (merged) into a public keyring. Then, one can check the signatures. Continuing the example, after obtaining the xANNA registrar keys in a file named xANNA_KEYS.txt, they are imported:
$ gpg --import xANNA_KEYS.txt gpg: key 55FB53736A5F408B: "Robert Hyerle (ranger6<EMAIL_ADDRESS>imported gpg: Total number processed: 1 gpg: no ultimately trusted keys found $
The note about "no ultimately trusted keys found" refers to the fact that the imported key is not verified by someone else that you have indicated as trusted. You will see a similar warning below when verifying the artifact. One trusts the xANNA Registrar key because you got it from a trusted source who you believe knows how to handle keys.
Now, the xANNA signature on the MIB file can be checked:
$ gpg --verify artifact.txt.asc gpg: assuming signed data in 'artifact.txt' gpg: Signature made Tue Dec 25 17:10:46 2018 CET gpg: using DSA key 3EAA2DC11757400AEA2EA7C8CD97C16346FC2C5F gpg: issuer<EMAIL_ADDRESS>gpg: Good signature from "Robert Hyerle (ranger6<EMAIL_ADDRESS>gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. $


This process requires a computer programmer proficient in PHP. They would need the application to access the new data source on the application’s nightly cron to run an overnight process. There exist some core classes that can help with the data processing (both as a template and as a resource). These are in the module’s classes/
directory.
The following steps would need to be taken:
small_base.php
.This data source could provide any of the following or something else:
This entire process would need to require some give-and-take initially between programmers. As the application matures, this process should be refined into an easier process.


It is 1957. Home alone, the 10 year old Hogarth Hughes is eating Twinkies and watching television, while his waitress mother is at work. He is enrapt by a scene in a scary late-night science fiction movie about brains crawling across a laboratory floor. Since reports have been circulating about the arrival of a UFO into the ocean waters near his small seacoast town of Rockwell, Maine, the self-reliant Hogarth is prepared for nearly anything. When all of a sudden the reception on the television begins to fade, he goes to the rooftop and investigates. Somebody or something has taken a huge bite out the antenna. After noticing immense tracks in the dirt leading away from his house, he descends in the woods with a BB gun in hand to confront what must be a space monster.
So begins a powerful animated film titled "The Iron Giant," based on a novel by Ted Hughes, England's poet laureate, written in 1968. Hughes, who died in 1998, wrote "The Iron Man" to comfort his young son after the death of his mother, the poet Sylvia Plath, in 1963. It is about, among other things, the persistence of life in the midst of death.
Surely enough he discovers an immense iron giant robot eating metal parts from an electrical power station in the dead of night, as languidly as a gorilla nibbling on vegetation. When the iron giant accidentally touches a generator, he is jolted by a huge electrical charge which threatens to kill it. Making a snap decision--one that sets the plot in motion for the remainder of this great animated film--Hogarth runs through falling metal and arcs of high-voltage electricity to shut down the power. After the iron giant regains consciousness, he follows Hogarth home.  As it turns out, the iron giant is the source of the rumors flying about Rockwell since it is he who has plunged into the ocean a few days earlier and swum to shore. Wandering about the woods of rural Maine, he has been subsisting on metal wherever he can find it--in parked cars or power stations.
Hogarth soon learns that Kent Mansley, a government agent and the villain of the movie, is on the tracks of the iron giant, since anything un-American in 1957 is considered a threat to national security, whether it comes from Russia or outer space. After discovering that the giant is harmless unless attacked, Hogarth becomes his best friend and protector. Hidden away in the barn next to his house, the boy is teaching the robot the ways of the planet earth mainly through comic books like Superman and Mad. As he turns through their pages, we learn that their omnipresent theme is the threat of nuclear war. In one story, Superman defends the planet earth against a radioactive monster. The iron giant, who is slowly learning to speak, tells Hogarth that he wants to be like Superman. At school, the threat of nuclear war is every bit as real as it is in the comic books and in science fiction movies. They watch a movie called "Duck and Cover" that shows children how easy it is to survive a nuclear attack. Just duck and cover.
Hogarth finds an unlikely ally in the local beatnik sculptor Dean, who lives and works at a junkyard. He works there because he can use the scrap iron in his "far out" sculpture. After Hogarth has introduced him to the iron giant, Dean wastes no time putting him to work. He directs the giant to stack old cars one on top of another in a monumental sculpture. Those that aren't used in the artwork go directly into the giant's stomach. Dean, who is the polar opposite of Mansley, is a forerunner of the cultural and political changes that would emerge in the 1960s. He was one of the rebels "who distributed Supercommunist pamphlets in Union Square weeping and undressing while the sirens of Los Alamos wailed them down," as Allen Ginsberg put it in the landmark poem "Howl".
This film has all the appeal of "ET" or "Terminator part two". The myth of a child taking an extraterrestrial or dangerous monster under his wing and teaching him the ways of his world is vastly alluring. What gives "The Iron Giant" additional appeal is that this relationship is set against the very real backdrop of global annihilation in the 1950s, when the threat of all-out nuclear war was very much on the mind of all children, including myself. Hogarth Hughes was exactly the kind of animated feature character I could have identified with, and one, I'm sure, that contemporary ten year olds, both male and female, can identify with. The movie offers an alternative to the sentimental pap of the Disney studio as well. Instead of presenting challenges drawn from the world of fairy tales with a "politically correct" overlay, director Brad Bird confronts the real evil that lived and lives in American society. The voice of Hogarth Hughes is done by 12 year old Elie Marienthal, while Harry Connick Jr. is Dean and Christopher MacDonald is the government agent Mansley.
--
Marxist discussion is at: www.panix.com/~lnp3/marxism.html
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


SCENARIO 7: One input field [Category Set: Input Field Multiplicity]
INPUTS
GROUP 1: Scalars
GROUP 2: Scenarios
| # | Category Set | Scenario | Active |
| 1 | Generic | Scenario one | N |
GROUP 3: Input Group
| # | Group Name | Field Name | Value |
| 1 | Input Group 1 | Input Field 1 | Input Value 1 |
GROUP 4: Output Group
| # | Group Name | Field Name | Value |
| 1 | Output Group 1 | Output Field 1 | Output Value 1 |
OUTPUTS
GROUP 1: Meta Input Group
| # | Group Name | Field Name |
| 1 | Input Group 1 | Input Field 1 |
0 failed of 1: SUCCESS
GROUP 2: Meta Output Group
| # | Group Name | Field Name |
| 1 | Output Group 1 | Output Field 1 |
0 failed of 1: SUCCESS
GROUP 3: Scenarios
| # | Category Set | Scenario | Active |
| 1 | Generic | Scenario one | N |
0 failed of 1: SUCCESS
GROUP 4: Scenario Input Group
| # | Scenario | Group Name | Record |
| 1 | Scenario one | Input Group 1 | Input Value 1 |
0 failed of 1: SUCCESS
GROUP 5: Scenario Output Group
| # | Scenario | Group Name | Record |
| 1 | Scenario one | Output Group 1 | Output Value 1 |
0 failed of 1: SUCCESS
GROUP 6: Unhandled Exception: Empty as expected: SUCCESS
0 failed of 6: SUCCESS