Quality – the product is consistently good quality and appealing Innovation - the product is innovative and adds something new to the marketplace Demonstration – the functionality of the product is apparent Price – the price-point is appropriate for the product
Product Description – the product is described clearly, including the problem it solves and the value it adds Intro & Closing – pitch begins with a friendly, engaging opening and ends with a clear “ask” or closing Presentation Skills – good physical composure (posture, pacing, hand gestures), eye contact and voice projection Passion – the sales pitch is enthusiastic, persuasive and passionate
Timely - Customer was greeted in a timely, friendly, professional manner Responsive – team responded to questions and concerns quickly, thoroughly and professionally Transaction – transaction process was smooth and professional Collaboration – all team members contributed to providing strong customer service
Organization – display was organized and neatly put together Informative – display contained all relevant information about the business (price, contact info, etc.) Attractive – display was visually appealing and attracted customers and sales


Платформа автоматизации — тесты результатов работы
The automation framework supports testing the job outcomes based on conditions that you can set in the YAML file.
The currently supported tests are:
- alert - Alert tests - validate the presence or absence of specified alerts
- monitor - Monitor tests - allow you to stop long running jobs based on statistic thresholds
- stats - Statistics tests - test any of the statistics maintained by ZAP
- url - URL tests - validate the presence/absence of a URL and it’s specific expressions in the HTTP response/request


{% extends "layout_unbranded.html" %} {% block page_title %} Actions - Family Mediator API {% endblock %} {% block content %} {% if serviceName %} {{ serviceName }} {% endif %} Upload mediators spreadsheet Updates will be processed immediately. Upload now You'll need: the mediators spreadsheet saved in XSLX format. {% endblock %}
Updates will be processed immediately.
Upload now


What is XMake?
XMake is a modern C/C++ build system based on Lua.
Its grammar is concise and easy to use, friendly to novices, even if you don’t know Lua at all, you can get started quickly, and it is completely free of any dependencies, lightweight, and cross-platform.
At the same time, it is also a self-satisfied build system with a powerful package management system and a fast build engine.
Compared with Ninja/Scons/Make as Build backend
, CMake/Meson as Project Generator
, and XMake not only provides Build backend
and Project Generator
at the same time, it also provides a built-in package manager.
xmake = Build backend + Project Generator + Package Manager
Therefore, you only need to install an XMake installation package that is less than 3M, and you don’t need to install other tools. You don’t even need to install make, and you don’t need to install heavyweight runtime environments such as Python and Java. You can quickly start your C/C++ development journey.
Maybe someone will say that the compiler always needs to be installed. This is not necessary, because XMake’s package management also supports automatically to pull remote compilation toolchains, such as llvm, Mingw, Android NDK or cross-compilation toolchain.
Why do XMake
Whenever discussing XMake with others in the Reddit community, everyone will always use the following picture to complain.
Although I was a little helpless and numb by the complaints, I still want to explain that the original intention of XMake was not to split the C/C++ ecology. On the contrary, XMake reuses the existing ecology as much as possible.
At the same time, it also allows users to have the same good experience as other languages when developing C/C++ projects, such as Rust/Cargo, Nodejs/Npm, Dlang/Dub, instead of looking for the third package everywhere, and studying how to transplant and compile. toss.
Therefore, if you don’t know XMake, please don’t draw conclusions too early, you can try it first, or take a moment to read the detailed introduction below.
Features and advantages of XMake
People often ask me what is special about XMake and what are the advantages compared to existing build tools such as CMake and Meson. Why should I use XMake instead of CMake?
Let me talk about the features and advantages first, XMake has the following points:
- Concise and easy-to-learn configuration syntax, non-DSL
- Powerful package management, support semantic version, toolchain management
- Lightweight enough, no dependence
- Fast, the build speed is as fast as Ninja
- Simple and convenient multi-platform and toolchain switching
- Complete plugin system
- Flexible build rules
XMake can be used as a supplement for those newcomers who want a simple and quick start to C/C++ development, or want more convenient and easy-to-use package management, or want to quickly write some short test projects temporarily.
XMake can help them improve development efficiency and make them pay more attention to the C/C++ project itself instead of spending more time on building tools and development environments.
Now, let us introduce these main features of XMake in detail.
Simple syntax
CMake designs a DSL language for project configuration, which increases learning costs for users, and its grammatical readability is not very intuitive, it is easy to write overly complex configuration scripts, and also increases maintenance costs.
XMake reuses the existing well-known Lua language as its foundation, and provides a simpler and more straightforward configuration syntax.
Lua itself is a simple and lightweight language. There are only a few keywords and built-in types. Just read an article and you can basically get started. Compared with DSL, you can get a lot of relevant information more conveniently from the Internet.
Basic syntax
However, some people still complain: don’t you still have to learn Lua?
In fact, it is not necessary. XMake adopts the method of separating the description field and the script field, so that in 80% of the cases, beginner users only need to configure the description field in a simpler and more direct way. It is completely unnecessary to configure it. As a Lua script, for example:
target("test")
set_kind("binary")
add_files("src/*.c")
add_files("test/*.c", "example/**.cpp")
If because of the parentheses, it is still like a function call of a scripting language, then we can also write it like this (whether to bring the parentheses depends on personal preference, but I personally recommend the above method)
target "test"
set_kind "binary"
add_files "src/*.c"
add_files "test/*.c"
add_files "example/**.cpp"
We only need to know the common configuration interface, even if we don’t know Lua at all, we can quickly configure it.
We can compare the configuration of CMake:
add_executable(test "")
file(GLOB SRC_FILES "src/*.c")
file(GLOB TEST_FILES "test/*.c")
file(GLOB_RECURSE EXAMPLE_FILES "example/*.cpp")
target_sources(test PRIVATE
${SRC_FILES}
${TEST_FILES}
${EXAMPLE_FILES}
)
Which is more intuitive and readable, at a glance.
Condition configuration
If you have a preliminary understanding of some basic knowledge such as Lua, such as conditional judgments such as if then
, then you can further configure some conditions.
target("test")
set_kind("binary")
add_files("src/main.c")
if is_plat("macosx", "linux") then
add_defines("TEST1", "TEST2")
end
if is_plat("windows") and is_mode("release") then
add_cxflags("-Ox", "-fp:fast")
end
Continue to compare the CMake version configuration:
add_executable(test "")
if (APPLE OR LINUX)
target_compile_definitions(test PRIVATE TEST1 TEST2)
endif()
if (WIN32)
target_compile_options(test PRIVATE $<$<CONFIG:Release>:-Ox -fp:fast>)
endif()
target_sources(test PRIVATE
src/main.c
)
Complex script
If you have basically mastered xmake and are familiar with lua syntax and you want more flexible customized configuration, then XMake also provides more complete Lua script customization capabilities, and you can write any complex script.
For example, before building, do some preprocessing of all source files, after building, execute external gradle commands for later packaging, and even we can rewrite internal link rules to achieve deep custom compilation. We can use import interface, import the built-in linker extension module to realize complex and flexible linking process.
target("test")
set_kind("binary")
add_files("src/*.c")
before_build_file(function (target, sourcefile)
io.replace(sourcefile, "#define HAVE_XXX 1", "#define HAVE_XXX 0")
end)
on_link(function (target)
import("core.tool.linker")
linker.link("binary", "cc", target:objectfiles(), target:targetfile(), {target = target})
end)
after_build(function (target)
if is_plat("android" then
os.cd("android/app")
os.exec("./gradlew app:assembleDebug")
end
end)
If you use CMake, you can also implement it in add_custom_command, but it seems that you can only simply execute some batch commands, and you can’t do all kinds of complex logic judgments, module loading, custom configuration scripts, and so on.
Of course, using cmake can certainly achieve the functions described above, but it is definitely not that simple.
If you are familiar with cmake, you can also try to help complete the following configuration:
add_executable(test "")
file(GLOB SRC_FILES "src/*.c")
add_custom_command(TARGET test PRE_BUILD
- TODO
COMMAND echo hello
)
add_custom_command(TARGET test POST_BUILD
COMMAND cd android/app
COMMAND ./gradlew app:assembleDebug
)
- How can we override link stage?
target_sources(test PRIVATE
${SRC_FILES}
)
Powerful package management
As we all know, in the development of C/C++ related projects, the most important thing is the integration of various dependent packages, because there is no complete package management system like Rust/Cargo.
Therefore, every time we want to use a third-party library, we need to find and study the porting and compilation of various platforms, and we often encounter various compilation problems, which greatly delays the developer’s time and cannot concentrate on the actual The project is under development.
Finally, the current platform is done. If you change to another platform, you need to toss the dependency package again. In order to solve this problem, some third-party package managers, such as vcpkg/conan/conda, etc., have appeared, but some do not support semantic versions. , Some supported platforms are limited, but no matter what, it is a big step towards solving the dependency management of the C/C++ library.
However, with the package manager alone, it is still more troublesome to use them in C/C++ projects, because the corresponding build tools also need to be able to integrate and support them well.
CMake and Vcpkg
Let’s first look at the integrated support of CMake and Vcpkg:
cmake_minimum_required(VERSION 3.0)
project(test)
find_package(unofficial-sqlite3 CONFIG REQUIRED)
add_executable(main main.cpp)
target_link_libraries(main PRIVATE unofficial::sqlite3::sqlite3)
Disadvantages:
- Additional configuration is required `-DCMAKE_TOOLCHAIN_FILE=
/scripts/buildsystems/vcpkg.cmake - Does not support automatic installation of dependent packages, and requires the user to manually execute the
vcpkg install xxx
command to install - The semantic version of vcpkg is not supported (it is said that the new version is supported)
CMake and Conan
```cmake
cmake_minimum_required(VERSION 2.8.12)
project(Hello)
add_definitions("-std=c++11")
include(${CMAKE_BINARY_DIR}/conanbuildinfo.cmake)
conan_basic_setup()
add_executable(hello hello.cpp)
target_link_libraries(hello gtest)
conanfile.txt
[requires]
gtest/1.10.0
[generators]
cmake
Disadvantages:
- Similarly, you still need to call
conan install ..
to install the package - An additional conanfile.txt file needs to be configured to describe package dependency rules
Meson and Vcpkg
I didn’t find how to use the vcpkg package in Meson. I just found a related Issue #3500 discussion.
Meson and Conan
It seems that Meson has not yet supported Conan, but there is a solution in the official Conan document to support alignment, but it is very complicated. I didn’t see it. You can research it yourself: https://docs.conan.io/en/ latest/reference/build_helpers/meson.html
XMake and Vcpkg
I have talked about so much before. The integration of other build tools and package management feels very troublesome to use, and different package managers have very different integration methods. Users want to quickly switch from Vcpkg to the Conan package, and the amount of change is very large. .
Next, let’s take a look at the packages provided by Vcpkg integrated in XMake:
add_requires("vcpkg::zlib", {alias = "zlib"})
target("test")
set_kind("binary")
add_files("src/*.c")
add_packages("zlib")
We only need to use the corresponding package name on the add_requires
configuration and the vcpkg::
package namespace to directly integrate and use the zlib package provided by vcpkg.
Then, we only need to execute the xmake command to complete the entire compilation process, including the automatic installation of the zlib package, without the need to manually execute vcpkg install zlib
.
$ xmake
note: try installing these packages (pass -y to skip confirm)?
-> vcpkg::zlib
please input: y (y/n)
=> install vcpkg::zlib .. ok
[25%]: compiling.release src\main.cpp
[50%]: linking.release test
[100%]: build ok!
XMake and Conan
The next step is to integrate the Conan package, in exactly the same way, just change the package manager name.
add_requires("conan::zlib", {alias = "zlib"})
target("test")
set_kind("binary")
add_files("src/*.c")
add_packages("zlib")
XMake will also automatically install the zlib package in conan, and then automatically integrate and compile.
XMake self-built package management
XMake and CMake have other build systems. The biggest difference, and one of the biggest advantages, is that it has a completely self-built package management system. We can not rely on vcpkg/conan at all, and can also quickly integrate dependent packages, such as :
add_requires("zlib 1.2.x", "tbox >= 1.6.0")
target("test")
set_kind("binary")
add_files("src/*.c")
add_packages("zlib", "tbox")
Moreover, it also supports complete semantic version selection, multi-platform package integration, cross-compilation tool chain package integration, and even automatic pull and use of compilation tool chain packages.
Not only that, but we can also rely on self-built packages for customized configurations, such as:
Use the debug version to depend on the package
We can use the debug version library to implement breakpoint debugging of dependent libraries.
add_requires("zlib", {debug = true})
Set msvc runtime library
add_requires("zlib", {configs = {vs_runtime = "MD"}})
Use dynamic libraries
The default integrated is static library, we can also switch to dynamic library.
add_requires("zlib", {configs = {shared = true}})
Semantic version support
XMake’s self-built package integration supports complete version semantic specifications.
add_requires("zlib 1.2.x")
add_requires("zlib >=1.2.10")
add_requires("zlib ~1.2.0")
Prohibit the use of system libraries
By default, if the versions match, XMake will give priority to searching and using the libraries that the user has installed on the system. Of course, we can also forcibly prohibit the search and use of system libraries, and only download the installation package from the self-built package repository.
add_requires("zlib", {system = true})
Optional dependency package
If the dependent package integration fails, XMake will automatically report an error, interrupt the compilation, and prompt the user: zlib not found
, but we can also set it as optional package integration. In this way, even if the library is not installed successfully, it will not affect the compilation of the project. , Just skip this dependency.
add_requires("zlib", {optional = true})
Package customization configuration
For example, the integration uses the boost library with the context/coroutine module configuration enabled.
add_requires("boost", {configs = {context = true, coroutine = true}})
Support package management repository
In addition to supporting vcpkg/conan and self-built repository package integration support, XMake also supports other package management repositorys, such as Conda/Homebrew/Apt/Pacman/Clib/Dub, etc., and the integration method is exactly the same.
Users can quickly switch to use other repository packs without spending too much time studying how to integrate them.
Therefore, XMake does not destroy the C/C++ ecology, but greatly reuses the existing C/C++ ecology, and strives to improve the user experience of C/C++ dependent packages, improve development efficiency, and enable users to have more More time to focus on the project itself.
- Official self-built repository xmake-repo (tbox >1.6.1)
- Official package manager Xrepo
- User-built repository
- Conan (conan::openssl/1.1.1g)
- Conda (conda::libpng 1.3.67)
- Vcpkg (vcpkg:ffmpeg)
- Homebrew/Linuxbrew (brew::pcre2/libpcre2-8)
- Pacman on archlinux/msys2 (pacman::libcurl)
- Apt on ubuntu/debian (apt::zlib1g-dev)
- Clib<EMAIL_ADDRESS>- Dub (dub::log 0.4.3)
Independent package management command (Xrepo)
In order to facilitate the package management in XMake’s self-built repository and the management and use of third-party packages, we also provide an independent Xrepo cli command tool to facilitate the management of our dependent packages
We can use this tool to quickly and easily complete the following management operations:
- Installation package:
xrepo install zlib
- Uninstall the package:
xrepo remove zlib
- Get package information:
xrepo info zlib
- Get package compilation link flags:
xrepo fetch zlib
- Load package virtual shell environment:
xrepo env shell
(this is a very powerful feature)
We can go to Xrepo Project Homepage to see more introduction and usage.
Lightweight and no dependencies
To use Meson/Scons, you need to install python/pip first. To use Bazel, you need to install a runtime environment such as java. XMake does not need to install any additional dependent libraries and environments. Its own installation package is only 2-3M, which is very lightweight.
Although XMake is based on lua, thanks to the lightweight features of the lua glue language, xmake has fully built-in it, so installing XMake is equivalent to having a complete lua vm.
Some people will say that the compilation tool chain is always needed, not completely. On Windows, we provide a pre-compiled installation package, which can be downloaded and installed directly. The address is: Releases
In addition, XMake also supports remotely pulling the compilation toolchain, so even if your system environment has not installed any compiler, it doesn’t matter, users don’t have to worry about how to toss the compilation environment, only need to configure the tools needed in xmake.lua The chain is fine.
For example, if we use the mingw-w64 tool chain to compile C/C++ projects on Windows, we only need to do the following configuration.
add_requires("mingw-w64")
target("test")
set_kind("binary")
add_files("src/*.c")
set_toolchains("mingw@mingw-w64")
After binding the mingw-w64 toolchain package through the set_toolchains
configuration, XMake will automatically detect whether mingw-64 exists in the current system. If it has not been installed, it will automatically download and install, and then complete the project compilation. It can be done by executing the command xmake
.
$ xmake
note: try installing these packages (pass -y to skip confirm)?
in xmake-repo:
-> mingw-w64 8.1.0 [vs_runtime:MT]
please input: y (y/n)
=> download https://jaist.dl.sourceforge.net/project/mingw-w64/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/8.1.0/threads-posix/seh/x86_64-8.1.0 -release-posix-seh-rt_v6-rev0.7z .. ok
checking for mingw directory ... C:\Users\ruki\AppData\Local\.xmake\packages\m\mingw-w64\8.1.0\aad6257977e0449595004d7441358fc5
[25%]: compiling.release src\main.cpp
[50%]: linking.release test.exe
[100%]: build ok!
In addition to mingw-w64, we can also configure remote pull to use other tool chains, and even cross-compile tool chains, such as: llvm-mingw, llvm, tinycc, muslcc, gnu-rm, zig, etc.
If you want to learn more about the pull integration of the remote toolchain, you can read the document: Automatically pull the remote toolchain.
Extremely fast parallel compilation
Everyone knows that Ninja builds very fast, so many people like to use CMake/Meson to generate build.ninja, and then use Ninja to meet the needs of extremely fast builds.
Although Ninja is fast, we still need to generate build.ninja through the meson.build and CMakelist.txt files first. This generation process will take several seconds or even ten seconds.
And XMake not only has almost the same build speed as Ninja, but also does not need to generate additional build files. It has a built-in build system directly. In any case, only one xmake
command can be used to achieve extremely fast compilation.
We have also done some comparative test data for your reference:
Multi-task parallel compilation test
| Build System | Termux (8core/-j12) | Build System | MacOS (8core/-j12) |
|---|---|---|---|
| xmake | 24.890s | xmake | 12.264s |
| ninja | 25.682s | ninja | 11.327s |
| cmake(gen+make) | 5.416s+28.473s | cmake(gen+make) | 1.203s+14.030s |
| cmake(gen+ninja) | 4.458s+24.842s | cmake(gen+ninja) | 0.988s+11.644s |
Single task compilation test
| Build System | Termux (-j1) | Build System | MacOS (-j1) |
|---|---|---|---|
| xmake | 1m57.707s | xmake | 39.937s |
| ninja | 1m52.845s | ninja | 38.995s |
| cmake(gen+make) | 5.416s+2m10.539s | cmake(gen+make) | 1.203s+41.737s |
| cmake(gen+ninja) | 4.458s+1m54.868s | cmake(gen+ninja) | 0.988s+38.022s |
Fool-style multi-platform compilation
Another feature of XMake is efficient and simple multi-platform compilation, whether you are compiling programs under windows/linux/macOS, compiling iphoneos/android or cross compiling.
Compilation configuration methods are similar, so users don’t need to go here to study how to compile under various platforms.
Compile native Windows/Linux/MacOS programs
The current native program compilation, we only need to execute:
$ xmake
CMake
$ mkdir build
$ cd build
$ cmake --build ..
Compile Android program
$ xmake f -p android --ndk=~/android-ndk-r21e
$ xmake
CMake
$ mkdir build
$ cd build
$ cmake -DCMAKE_TOOLCHAIN_FILE=~/android-ndk-r21e/build/cmake/android.toolchain.cmake ..
$ make
Compile iOS program
$ xmake f -p iphoneos
$ xmake
CMake
$ mkdir build
$ cd build
$ wget https://raw.githubusercontent.com/leetal/ios-cmake/master/ios.toolchain.cmake
$ cmake -DCMAKE_TOOLCHAIN_FILE=`pwd`/ios.toolchain.cmake ..
$ make
I didn’t find a very convenient way to configure and compile the ios program. I could only find a third-party ios tool chain from other places to configure and compile.
Cross compilation
We usually only need to set the root directory of the cross-compilation toolchain. XMake will automatically detect the toolchain structure and extract the compiler inside to participate in the compilation. No additional configuration is required.
$ xmake f -p cross --sdk=~/aarch64-linux-musl-cross
$ xmake
CMake
We need to write an additional cross-toolchain.cmake configuration file first.
set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR aarch64)
set(TOOL_CHAIN_DIR ~/aarch64-linux-musl)
set(TOOL_CHAIN_INCLUDE ${TOOL_CHAIN_DIR}/aarch64-linux-musl/include)
set(TOOL_CHAIN_LIB ${TOOL_CHAIN_DIR}/aarch64-linux-musl/lib)
set(CMAKE_C_COMPILER "aarch64-linux-gcc")
set(CMAKE_CXX_COMPILER "aarch64-linux-g++")
set(CMAKE_FIND_ROOT_PATH ${TOOL_CHAIN_DIR}/aarch64-linux-musl)
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
include_directories(${TOOL_CHAIN_DIR}/aarch64-linux-musl/include)
set(CMAKE_INCLUDE_PATH ${TOOL_CHAIN_INCLUDE})
set(CMAKE_LIBRARY_PATH ${TOOL_CHAIN_LIB})
$ mkdir build
$ cd build
$ cmake -DCMAKE_TOOLCHAIN_FILE=../cross-toolchain.cmake ..
$ make
Conclusion
If you are new to C/C++ development, you can use XMake to quickly get started with C/C++ compilation and construction.
If you want to develop and maintain a cross-platform C/C++ project, you can also consider using XMake to maintain the build, improve development efficiency, and let you focus more on the project itself, and no longer worry about tossing about transplanting dependent libraries.
Welcome to the XMake project:


THE KING AND I A movie review by Joe Barlow (c) Copyright 1999
STARRING (the voices of): Miranda Richardson, Martin Vidnovic, Alan Hong, Armi Arabe, Ian Richardson, Darryl Hammond DIRECTOR: Richard Rich WRITERS: Richard Rogers, Oscar Hammerstein II, Arthur Rankin, Peter Bakalian, Jacqueline Feather, David Seidler RATED: G RELEASED: 1999
RATING: * 1/2 (out of a possible ****)
Warner Brothers' "The King and I" is an animated retelling of the Rodgers and Hammerstein stage classic, or at least that's what it claims; in truth, it's more mockery than homage. The film is the cinematic equivalent of Cliff-notes, to be employed by those who don't have the attention span for anything longer or more intellectually challenging than a "Road Runner" cartoon.
At cursory glance, the plot appears to be the same: a British schoolteacher named Anna (Miranda Richardson) is offered a job as tutor to the King of Siam's children. She accepts, on one condition: she wishes to be given a house of her own, located outside the palace walls. Although the king (Martin Vidnovic) agreed to this stipulation via letter, he is much less reluctant to grant the wish once Anna and her son actually make it to Siam. But the teacher is a fiercely determined woman, not afraid to stand up for her rights; soon the king grows fascinated with the intelligence and charisma of the new arrival. Although the monarch and the teacher come from varying backgrounds, they are eventually able to put aside their differences and strike up a friendship.
That's about where the similarities between the two versions of the story end. This new animated incarnation cheerfully jettisons all the thought-provoking aspects of the original work (like the conflicting emotions the king feels over the issue of slavery, or his confusion over how the world could've been created in six days according to the Bible, when science clearly says it took millions of years). This "adaptation" (I call it butchery) is strictly vanilla fare, with all the meat watered down to the point where it tastes indistinguishable from the broth.
So what does director Richard Rich do with the leftover space which remains after he's stripped away half the story? Why, add a bunch of cartoon staples, of course. Since it's impossible to make an animated feature without including a number of easily marketable animal sidekicks, the film gives Anna's son Louis (Adam Wylie) an obnoxious pet monkey. The King himself gets a jet-black panther named Rama, and slave-girl Tuptim (Armi Arabe) befriends an adorably big-eyed baby elephant that seems to be in this movie for no other purpose than to give Warner Brothers a stuffed animal that's guaranteed to fly off toy store shelves.
The original "The King and I" had no central villain, per se.  But since you can't make an action figure out of "ignorance," this adaptation has turned the King's Prime Minster, Kralahome (Ian Richardson), into an archetypal evil villain stereotype. He appears to be the twin brother of Aladdin's Jafar, both physically and mentally: Kralahome possesses sorcerer's powers, has mad ambitions of ruling the kingdom, and will stop at nothing to dethrone the king (although he takes time periodically to leer and break into demented laughter, to make sure the audience knows that he's evil).  Little is just as flat and cliched as his boss; although the children at the screening I attended seemed delighted by his madcap antics, I found him infuriating, particularly during a ridiculous subplot involving Little's tendency to involuntarily lose his teeth. Why does a story that's supposed to be a tragedy need such obnoxious comic relief?
I say "supposed to be," because this film turns the thought- provoking scenes of the original story into a trite, giddy smile-fest. Gone is the heartwrenching moment in which the king dies of a mysterious illness (which appears to be a broken heart), replaced with a chase scene involving a hot-air balloon and a couple of elephants. I expected the king to be a brave man, but who knew he was a Jackie Chan-wanna be?
Perhaps most disappointing is the way the original tale's emotional axis, the forbidden love affair between Tuptim and a freeman, is relegated to a status of irrelevance. The affair ends tragically in the original film, giving the king (and the audience) much to think about. But here, Tuptim's love interest is none other than the crown prince himself (who was a boy in the earlier version, but appears to be roughly sixteen here); therefore, all sense of tension is immediately irradicated. Obviously the king is not going to harm his son, so these scenes play off as nothing more than cheap formula: the conclusion that they'll live happily ever after is foreordained, but nonetheless, cliche' requires the inclusion of a romance, leaving a story that proceeds so transparently that there is no way for us to be surprised by anything we're seeing.
The movie is not devoid of merit, however. The animation is spectacular-- so good that the film may actually be worth a peek simply to bask in its remarkably vivid colors. Of particular note is a montage of scenes in the palace gardens, which are rendered so brightly and beautifully that I actually whispered the word "Wow." The tune "Getting to Know You" also puts in a stellar appearance here: in the original movie, the song is performed by Anna and the children in their palace classroom; here, Anna takes the kids on a field trip to the village just outside the palace gates (which the kids have never seen). It gives new meaning to the lyrics, and is clever and touching at the same time. Had the film been daring enough to reinterpret the material in this fashion more often, rather than "dumb it down," it could've provided a fresh new slant on a beloved story; as it stands, it's the only such moment in the movie.
This remake of "The King and I" is painfully disappointing.  Instead, we're given an overabundance of cuteness, a false-feeling happy ending, and cartoon cliches. This isn't so much "The King and I" as "The King and I and His Kids and the Villagers and a Pointless Romance and a Bunch of Animals and Cardboard Villains and our Merry Life Together in the Magical Land of Dreams..."; or, as the king himself might say, "Et cetera, et cetera, et cetera."
E-Mail<EMAIL_ADDRESS>Joe Barlow on Film: http://www.ipass.net/~jbarlow/film.htm
If you'd like to receive new film reviews by e-mail, please write to<EMAIL_ADDRESS>The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


This document aims to compare PicoContainer to other IoC containers, both lightweight and not.
There are a number of published API specifications since Java was initially released that proport to be container/component designs. We discuss then here, suggesting there are goals that some have met, and some not. This may help you make better design choices for your own components.
The Spring Framework is a J2EE framework. As such, Dependency Injection and Lifecycle is only one of its concerns. PicoContainer, on the other hand, is concerned only with Dependency Injection, configuration and Lifecycle.
(Avalon ceased development in 2005)
Apache hosted a project that had been running for many years called Avalon. It had many components that fit that its design and many containers is writtern in Java. Avalon components were characterised by implementation of many optional interfaces. Avalon components were distributed with meta-information in XML in the jar file. More XML is required to assemble components together for the same of a application. Avalon Phoenix, Excalibur Component Manager (ECM), Avalon Fortress and Avalon Merlin were the pertinent containers.
The Avalon Framework required implementing components to implement a number of interfaces. By the end of the the project, this had proven historically to be a bit of a turn-off for component writers. Those interfaces were :-
| Avalon Interface | PicoContainer equivalent |
|---|---|
| LogEnabled | Logging agnostic |
| Contextualizable | n/a |
| Serviceable (was Composable) | arguments are injected |
| Configurable | arguments are injected |
| Parameterizable | n/a |
| Initializable | Constructor is the equivalent lifecycle concept |
| Startable | Startable |
| Suspendable | n/a |
| Recontextualizable | n/a |
| Recomposable | n/a |
| Reconfigurable | n/a |
| Reparameterizable | n/a |
| Disposable | Disposable |
Avalon is a Contextualized Lookup IoC design.
import org.apache.avalon.framework.ServiceManager; import org.apache.avalon.framework.Serviceable; import org.apache.avalon.framework.ServiceException; public class Shop implements Serviceable, Initializable { StockManager stockManager; String shopZipCode; public void service(ServiceManager sm) throws ServiceException { stockManager = (StockManager) sm.lookup("StockManager"); } public void initialize() { // all service()ing has been done. } }
A component has to have service (component) declarations in an external file. The Loom container (forked from Phoenix) has .xinfo files for each component to meet such needs. All Avalon container have some mechanism for storing configuration and assembly externally to the class. Cross referenced against the xinfo files, Loom's assembly.xml defines the implementations to be used for component types. Thus all Avalon components must be interface/implementation separated. Another Avalon using server technology is Keel.
It has to be said that all post-Avalon projects are not as active as they could be.
The downside of the this design is that components can only be used without the container with great difficulty. If at all. Thus a proper container is needed at all times, and you have to choose one for different purposes. If you do manage to instantiate components without a container, you might miss one of the essential service dependencies. The component-using class will continue to compile, but at run time it will be apparent that there are missing dependencies. Because of the these complexities, unit testing with frameworks like JUnit is very difficult for of Avalon components.
Sun have specified several container/component designs over the years.
Clearly Entity and Session beans run inside a container. The API is well defined, and to varying degrees of success one can deploy EJB appllications to WebLogic, WebSphere, Orion and JBoss etc. For assembly and configuration, there is high use of element-normal XML . There are some mandated parent objects and interfaces for various to extend and/or implement. Resolution is done by the components themselves via JNDI more often than not.
PicoComponents are simpler in they they do not force an extensive XML markup, nor require the implementing of certaing interfaces or extening base classes. Quite importantly the relationship between factory (home), implementation (bean) and interface (remote) parts is much more real in Pico-style components. EJB 2.0 components are nearly impossible to unit-test without much effort.
With the advent of EJB 3.0 (which the our team directly influenced), things became easier for EJB developers. Annotations were used to mark fields, and methods for injection. Strangely constructors were not eligible for injection. It was reported back to the our team that it was felt that the J2EE container makers would not find it easy making multi-argument constructor injection a reality.
Not so obvious - Servlets are contained by a servlet container. They are generally bundled with (or replaced by) value added propositions like JSP, but it is still a container/component design. High use of XML for assembly and configuration. Servlets have no concept of parent container or the conatainer above that (sometimes EJB) and its provision of components, which is very unfortunate. Servlets have a number of interfaces to honor, none of which is too malignent. Servlets typically deal with external (or parent) components via RMI or JNDI. In more recent releases of EJB, local interfaces rather than RMI may be the mechanism for connection the parent components. WebLogic have always provided an optimizing mechanism for this interoperation
As with EJB, PicoComponents are far simpler. This is probably because they offer no web experience, without an extension. Servlets again are not that unit-testable.
Applets, though presently not so often used, are a good example of Container/Component separations. There is very little XML in use by Applets. Configuration is typically delivered in applet tags in HTML. Applets are granted some access to the parent container, the brower, and its DOM model for pages and other applets. There very little standardisation for Browser as a container.
As with EJB, PicoComponents are far simpler. Applets are unit-testable but with a little effort. Complex DOM interoperation is impossible under unit testing.
public static void main(String[] args) {}
Familiar? Hopefully not Static plays no part in a good IoC container/component design. This includes static launching of Java Webstart (JNLP) applications. If you have to keep mainable functionaility separate your components away from the main() class so they may be instntiated separately. In .NET you'll have to make sure that the application assembly is a small bootstrap to a component one.
A huge map of clunkily access components via a very non-IoC mechanism. It has to be strapped with much XML to prevent inappropriate access. This is not IoC because the component reaches out for external component dependancies whenever it feels like. This last fact clouds Serlvets and EJB use.
Nice container/component designs. In the case of Swing, perhaps a little difficult for coders to easily assemble applications.
The Eclipse platform is very compelling. It supports the notion of a pluggable application concept. Each component statically accesses other components via a factory (which at least Paul does not like), though it is clear that some complex classloader magic is going on. The underpinning set of graphical components, SWT , are a simple and elegant design.


I am an application developer with strong client side development.
I have been working in the industry since 2001, and I have a fundamental understanding of User Experience
My goal is to increase my skills, and maintain my record of applying strategic design and planning


title: CONTENT samplename: content sampleurl: https://github.com/MikeMitterer/dart-material-design-lite/tree/mdl/example/spa_content/web ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I am your main content - I live in index.html
Try to drag the second slider. Click on Slider and you'll see how the dynamically loaded slider.html reflects your changes in the main model! If the "Slider sample" is loaded drag one of the blue sliders. They return their value to the main model and you'll see all three sliders moving.


| \emFile:SPI0:BSPIM:sR8:Dp:u0\/so_comb |
\emFile:SPI0:BSPIM:mosi_pre_reg\/main_1 |
53.476 MHz |
18.700 |
22.967 |
|
| Type |
Location |
Fanout |
Instance/Net |
Source |
Dest |
Delay (ns) |
| datapathcell2 |
U(3,5) |
1 |
\emFile:SPI0:BSPIM:sR8:Dp:u0\ |
\emFile:SPI0:BSPIM:sR8:Dp:u0\/clock |
\emFile:SPI0:BSPIM:sR8:Dp:u0\/so_comb |
5.360 |
| Route |
|
1 |
\emFile:SPI0:BSPIM:mosi_from_dp\ |
\emFile:SPI0:BSPIM:sR8:Dp:u0\/so_comb |
\emFile:SPI0:BSPIM:mosi_pre_reg_split_1\/main_3 |
3.559 |
| macrocell65 |
U(3,4) |
1 |
\emFile:SPI0:BSPIM:mosi_pre_reg_split_1\ |
\emFile:SPI0:BSPIM:mosi_pre_reg_split_1\/main_3 |
\emFile:SPI0:BSPIM:mosi_pre_reg_split_1\/q |
3.350 |
| Route |
|
1 |
\emFile:SPI0:BSPIM:mosi_pre_reg_split_1\ |
\emFile:SPI0:BSPIM:mosi_pre_reg_split_1\/q |
\emFile:SPI0:BSPIM:mosi_pre_reg\/main_1 |
2.921 |
| macrocell40 |
U(2,3) |
1 |
\emFile:SPI0:BSPIM:mosi_pre_reg\ |
|
SETUP |
3.510 |
| Clock |
|
|
|
|
Skew |
0.000 |
|
| \emFile:SPI0:BSPIM:sR8:Dp:u0\/so_comb |
\emFile:SPI0:BSPIM:mosi_pre_reg\/main_0 |
53.507 MHz |
18.689 |
22.978 |
|
| Type |
Location |
Fanout |
Instance/Net |
Source |
Dest |
Delay (ns) |
| datapathcell2 |
U(3,5) |
1 |
\emFile:SPI0:BSPIM:sR8:Dp:u0\ |
\emFile:SPI0:BSPIM:sR8:Dp:u0\/clock |
\emFile:SPI0:BSPIM:sR8:Dp:u0\/so_comb |
5.360 |
| Route |
|
1 |
\emFile:SPI0:BSPIM:mosi_from_dp\ |
\emFile:SPI0:BSPIM:sR8:Dp:u0\/so_comb |
\emFile:SPI0:BSPIM:mosi_pre_reg_split\/main_3 |
3.567 |
| macrocell1 |
U(2,4) |
1 |
\emFile:SPI0:BSPIM:mosi_pre_reg_split\ |
\emFile:SPI0:BSPIM:mosi_pre_reg_split\/main_3 |
\emFile:SPI0:BSPIM:mosi_pre_reg_split\/q |
3.350 |
| Route |
|
1 |
\emFile:SPI0:BSPIM:mosi_pre_reg_split\ |
\emFile:SPI0:BSPIM:mosi_pre_reg_split\/q |
\emFile:SPI0:BSPIM:mosi_pre_reg\/main_0 |
2.902 |
| macrocell40 |
U(2,3) |
1 |
\emFile:SPI0:BSPIM:mosi_pre_reg\ |
|
SETUP |
3.510 |
| Clock |
|
|
|
|
Skew |
0.000 |
|
| \emFile:SPI0:BSPIM:state_1\/q |
\emFile:SPI0:BSPIM:mosi_pre_reg\/main_1 |
62.120 MHz |
16.098 |
25.569 |
|
| Type |
Location |
Fanout |
Instance/Net |
Source |
Dest |
Delay (ns) |
| macrocell36 |
U(3,5) |
1 |
\emFile:SPI0:BSPIM:state_1\ |
\emFile:SPI0:BSPIM:state_1\/clock_0 |
\emFile:SPI0:BSPIM:state_1\/q |
1.250 |
| Route |
|
1 |
\emFile:SPI0:BSPIM:state_1\ |
\emFile:SPI0:BSPIM:state_1\/q |
\emFile:SPI0:BSPIM:mosi_pre_reg_split_1\/main_1 |
5.067 |
| macrocell65 |
U(3,4) |
1 |
\emFile:SPI0:BSPIM:mosi_pre_reg_split_1\ |
\emFile:SPI0:BSPIM:mosi_pre_reg_split_1\/main_1 |
\emFile:SPI0:BSPIM:mosi_pre_reg_split_1\/q |
3.350 |
| Route |
|
1 |
\emFile:SPI0:BSPIM:mosi_pre_reg_split_1\ |
\emFile:SPI0:BSPIM:mosi_pre_reg_split_1\/q |
\emFile:SPI0:BSPIM:mosi_pre_reg\/main_1 |
2.921 |
| macrocell40 |
U(2,3) |
1 |
\emFile:SPI0:BSPIM:mosi_pre_reg\ |
|
SETUP |
3.510 |
| Clock |
|
|
|
|
Skew |
0.000 |
|
| \emFile:SPI0:BSPIM:sR8:Dp:u0\/f1_blk_stat_comb |
\emFile:SPI0:BSPIM:RxStsReg\/status_6 |
63.231 MHz |
15.815 |
25.852 |
|
| Type |
Location |
Fanout |
Instance/Net |
Source |
Dest |
Delay (ns) |
| datapathcell2 |
U(3,5) |
1 |
\emFile:SPI0:BSPIM:sR8:Dp:u0\ |
\emFile:SPI0:BSPIM:sR8:Dp:u0\/clock |
\emFile:SPI0:BSPIM:sR8:Dp:u0\/f1_blk_stat_comb |
3.580 |
| Route |
|
1 |
\emFile:SPI0:BSPIM:rx_status_4\ |
\emFile:SPI0:BSPIM:sR8:Dp:u0\/f1_blk_stat_comb |
\emFile:SPI0:BSPIM:rx_status_6\/main_5 |
4.189 |
| macrocell10 |
U(3,4) |
1 |
\emFile:SPI0:BSPIM:rx_status_6\ |
\emFile:SPI0:BSPIM:rx_status_6\/main_5 |
\emFile:SPI0:BSPIM:rx_status_6\/q |
3.350 |
| Route |
|
1 |
\emFile:SPI0:BSPIM:rx_status_6\ |
\emFile:SPI0:BSPIM:rx_status_6\/q |
\emFile:SPI0:BSPIM:RxStsReg\/status_6 |
4.196 |
| statusicell3 |
U(3,4) |
1 |
\emFile:SPI0:BSPIM:RxStsReg\ |
|
SETUP |
0.500 |
| Clock |
|
|
|
|
Skew |
0.000 |
|
| \emFile:SPI0:BSPIM:state_1\/q |
\emFile:SPI0:BSPIM:mosi_pre_reg\/main_0 |
63.255 MHz |
15.809 |
25.858 |
|
| Type |
Location |
Fanout |
Instance/Net |
Source |
Dest |
Delay (ns) |
| macrocell36 |
U(3,5) |
1 |
\emFile:SPI0:BSPIM:state_1\ |
\emFile:SPI0:BSPIM:state_1\/clock_0 |
\emFile:SPI0:BSPIM:state_1\/q |
1.250 |
| Route |
|
1 |
\emFile:SPI0:BSPIM:state_1\ |
\emFile:SPI0:BSPIM:state_1\/q |
\emFile:SPI0:BSPIM:mosi_pre_reg_split\/main_1 |
4.797 |
| macrocell1 |
U(2,4) |
1 |
\emFile:SPI0:BSPIM:mosi_pre_reg_split\ |
\emFile:SPI0:BSPIM:mosi_pre_reg_split\/main_1 |
\emFile:SPI0:BSPIM:mosi_pre_reg_split\/q |
3.350 |
| Route |
|
1 |
\emFile:SPI0:BSPIM:mosi_pre_reg_split\ |
\emFile:SPI0:BSPIM:mosi_pre_reg_split\/q |
\emFile:SPI0:BSPIM:mosi_pre_reg\/main_0 |
2.902 |
| macrocell40 |
U(2,3) |
1 |
\emFile:SPI0:BSPIM:mosi_pre_reg\ |
|
SETUP |
3.510 |
| Clock |
|
|
|
|
Skew |
0.000 |
|
| \emFile:SPI0:BSPIM:BitCounter\/count_4 |
\emFile:SPI0:BSPIM:sR8:Dp:u0\/f1_load |
64.549 MHz |
15.492 |
26.175 |
|
| Type |
Location |
Fanout |
Instance/Net |
Source |
Dest |
Delay (ns) |
| count7cell |
U(2,5) |
1 |
\emFile:SPI0:BSPIM:BitCounter\ |
\emFile:SPI0:BSPIM:BitCounter\/clock |
\emFile:SPI0:BSPIM:BitCounter\/count_4 |
1.940 |
| Route |
|
1 |
\emFile:SPI0:BSPIM:count_4\ |
\emFile:SPI0:BSPIM:BitCounter\/count_4 |
\emFile:SPI0:BSPIM:load_rx_data\/main_0 |
3.767 |
| macrocell6 |
U(3,4) |
1 |
\emFile:SPI0:BSPIM:load_rx_data\ |
\emFile:SPI0:BSPIM:load_rx_data\/main_0 |
\emFile:SPI0:BSPIM:load_rx_data\/q |
3.350 |
| Route |
|
1 |
\emFile:SPI0:BSPIM:load_rx_data\ |
\emFile:SPI0:BSPIM:load_rx_data\/q |
\emFile:SPI0:BSPIM:sR8:Dp:u0\/f1_load |
3.585 |
| datapathcell2 |
U(3,5) |
1 |
\emFile:SPI0:BSPIM:sR8:Dp:u0\ |
|
SETUP |
2.850 |
| Clock |
|
|
|
|
Skew |
0.000 |
|
| \emFile:SPI0:BSPIM:BitCounter\/count_4 |
\emFile:SPI0:BSPIM:mosi_pre_reg\/main_1 |
64.566 MHz |
15.488 |
26.179 |
|
| Type |
Location |
Fanout |
Instance/Net |
Source |
Dest |
Delay (ns) |
| count7cell |
U(2,5) |
1 |
\emFile:SPI0:BSPIM:BitCounter\ |
\emFile:SPI0:BSPIM:BitCounter\/clock |
\emFile:SPI0:BSPIM:BitCounter\/count_4 |
1.940 |
| Route |
|
1 |
\emFile:SPI0:BSPIM:count_4\ |
\emFile:SPI0:BSPIM:BitCounter\/count_4 |
\emFile:SPI0:BSPIM:mosi_pre_reg_split_1\/main_4 |
3.767 |
| macrocell65 |
U(3,4) |
1 |
\emFile:SPI0:BSPIM:mosi_pre_reg_split_1\ |
\emFile:SPI0:BSPIM:mosi_pre_reg_split_1\/main_4 |
\emFile:SPI0:BSPIM:mosi_pre_reg_split_1\/q |
3.350 |
| Route |
|
1 |
\emFile:SPI0:BSPIM:mosi_pre_reg_split_1\ |
\emFile:SPI0:BSPIM:mosi_pre_reg_split_1\/q |
\emFile:SPI0:BSPIM:mosi_pre_reg\/main_1 |
2.921 |
| macrocell40 |
U(2,3) |
1 |
\emFile:SPI0:BSPIM:mosi_pre_reg\ |
|
SETUP |
3.510 |
| Clock |
|
|
|
|
Skew |
0.000 |
|
| \emFile:SPI0:BSPIM:BitCounter\/count_0 |
\emFile:SPI0:BSPIM:sR8:Dp:u0\/f1_load |
64.625 MHz |
15.474 |
26.193 |
|
| Type |
Location |
Fanout |
Instance/Net |
Source |
Dest |
Delay (ns) |
| count7cell |
U(2,5) |
1 |
\emFile:SPI0:BSPIM:BitCounter\ |
\emFile:SPI0:BSPIM:BitCounter\/clock |
\emFile:SPI0:BSPIM:BitCounter\/count_0 |
1.940 |
| Route |
|
1 |
\emFile:SPI0:BSPIM:count_0\ |
\emFile:SPI0:BSPIM:BitCounter\/count_0 |
\emFile:SPI0:BSPIM:load_rx_data\/main_4 |
3.749 |
| macrocell6 |
U(3,4) |
1 |
\emFile:SPI0:BSPIM:load_rx_data\ |
\emFile:SPI0:BSPIM:load_rx_data\/main_4 |
\emFile:SPI0:BSPIM:load_rx_data\/q |
3.350 |
| Route |
|
1 |
\emFile:SPI0:BSPIM:load_rx_data\ |
\emFile:SPI0:BSPIM:load_rx_data\/q |
\emFile:SPI0:BSPIM:sR8:Dp:u0\/f1_load |
3.585 |
| datapathcell2 |
U(3,5) |
1 |
\emFile:SPI0:BSPIM:sR8:Dp:u0\ |
|
SETUP |
2.850 |
| Clock |
|
|
|
|
Skew |
0.000 |
|
| \emFile:SPI0:BSPIM:BitCounter\/count_4 |
\emFile:SPI0:BSPIM:mosi_pre_reg\/main_0 |
64.629 MHz |
15.473 |
26.194 |
|
| Type |
Location |
Fanout |
Instance/Net |
Source |
Dest |
Delay (ns) |
| count7cell |
U(2,5) |
1 |
\emFile:SPI0:BSPIM:BitCounter\ |
\emFile:SPI0:BSPIM:BitCounter\/clock |
\emFile:SPI0:BSPIM:BitCounter\/count_4 |
1.940 |
| Route |
|
1 |
\emFile:SPI0:BSPIM:count_4\ |
\emFile:SPI0:BSPIM:BitCounter\/count_4 |
\emFile:SPI0:BSPIM:mosi_pre_reg_split\/main_4 |
3.771 |
| macrocell1 |
U(2,4) |
1 |
\emFile:SPI0:BSPIM:mosi_pre_reg_split\ |
\emFile:SPI0:BSPIM:mosi_pre_reg_split\/main_4 |
\emFile:SPI0:BSPIM:mosi_pre_reg_split\/q |
3.350 |
| Route |
|
1 |
\emFile:SPI0:BSPIM:mosi_pre_reg_split\ |
\emFile:SPI0:BSPIM:mosi_pre_reg_split\/q |
\emFile:SPI0:BSPIM:mosi_pre_reg\/main_0 |
2.902 |
| macrocell40 |
U(2,3) |
1 |
\emFile:SPI0:BSPIM:mosi_pre_reg\ |
|
SETUP |
3.510 |
| Clock |
|
|
|
|
Skew |
0.000 |
|
| \emFile:SPI0:BSPIM:BitCounter\/count_0 |
\emFile:SPI0:BSPIM:mosi_pre_reg\/main_1 |
64.641 MHz |
15.470 |
26.197 |
|
| Type |
Location |
Fanout |
Instance/Net |
Source |
Dest |
Delay (ns) |
| count7cell |
U(2,5) |
1 |
\emFile:SPI0:BSPIM:BitCounter\ |
\emFile:SPI0:BSPIM:BitCounter\/clock |
\emFile:SPI0:BSPIM:BitCounter\/count_0 |
1.940 |
| Route |
|
1 |
\emFile:SPI0:BSPIM:count_0\ |
\emFile:SPI0:BSPIM:BitCounter\/count_0 |
\emFile:SPI0:BSPIM:mosi_pre_reg_split_1\/main_7 |
3.749 |
| macrocell65 |
U(3,4) |
1 |
\emFile:SPI0:BSPIM:mosi_pre_reg_split_1\ |
\emFile:SPI0:BSPIM:mosi_pre_reg_split_1\/main_7 |
\emFile:SPI0:BSPIM:mosi_pre_reg_split_1\/q |
3.350 |
| Route |
|
1 |
\emFile:SPI0:BSPIM:mosi_pre_reg_split_1\ |
\emFile:SPI0:BSPIM:mosi_pre_reg_split_1\/q |
\emFile:SPI0:BSPIM:mosi_pre_reg\/main_1 |
2.921 |
| macrocell40 |
U(2,3) |
1 |
\emFile:SPI0:BSPIM:mosi_pre_reg\ |
|
SETUP |
3.510 |
| Clock |
|
|
|
|
Skew |
0.000 |
|


| Project Lead | Project Co-Lead |
|---|---|
|
Kirti Rajagopalan CSANR, Washington State University |
Vince Jones WSU Tree Fruit Research and Extension Center |
| Programmer | Stakeholder engagement and Outreach | |
|---|---|---|
|
Giridhar Manoharan |
Ute Chambers |
Sonia Hall |
|
Von Walden |
Mingliang Liu |
Georgine Yorgey |
Chad Kruger |
Lee Kalcsits |
Claudio O. Stöckle |