One of the key features of Jawr is its ability to bundle resources. The process of bundling involves the following steps:
By default, this process is done at server startup. This bundling process could take some times, when the application contains a large number of bundles.
Since Jawr 3.0, we have added a feature to preprocess the Jawr bundles. The bundle preprocessing is almost the same as the standard processing, except that it could be done during a build.
We have added 2 properties:
When the property jawr.use.bundle.mapping is set to true, Jawr will try to use specific files, which are containing all the data about the bundles (Full mapping paths, bundle hash code ...). These files are searched in the working directory (jawrWrkDir/jawr-(js/css/img)-mapping.properties ). If these files are not found, Jawr will create them in the working directory.
So if you have this property set to true, and you start a fresh application with an empty working directory, the first time, Jawr will process the bundle normally and it will create the mapping files. Then the next time, when you restart your application, Jawr will use the mappings files and skip the bundling process, this will make the startup time of the web application faster.
Note: The full image mapping file located at jawrWrkDir/jawr-img-mapping.properties, will be generated from the image resources defined with the jawr.image.resources property and the CSS images used in the CSS bundles. So for an image which is referenced by an image tag, and which is not part of the image mapping, the hashcode will be generated at runtime, and put in cache.
We have added the option to define explicitly the location the working directory. By default the working directory is set in webAppWrkDir/jawrTmp/
The user could define the working directory location somewhere else on the file system using a value, which is prefixed by file://. For example:
jawr.working.directory=file://D:/temp/jawr/
The user could also define the working directory inside the web application itself. In that case, the value should be a relative path from the web application root directory. For example:
jawr.working.directory=/jawrContent/
But in that case, Jawr will not be able to create the temporary files in the web application. So this means that the user will have to create the temporary files, and put them in the web application.
This class is responsible of preprocessing the bundles, creating the Jawr working directory and the CDN directory.
In the working directory, you will have the content of Jawr working directory generated by Jawr.
In the CDN directory, you will have all the data for the CDN.
An Ant task and a maven plugin have been created to make it easy the integration in the build process. For more information about the usage, please check the documentation for the maven plugin and the Ant task.
To implement this feature, we have decided to simulate the server startup.
This means that we are faking the application server startup:
The main method of the bundle processor is the process method. This method takes 5 parameters:
As we have seen, the bundle preprocessing has almost the same behaviour as the standard bundle processing. To implement this feature, we have decided to simulate the server startup. By default we will only initialize the Jawr servlets. You could add in the servletsToInitialize the list of servlets to initialize.
As said above, we only fake a server startup, which means that we don't initialize the entire web application context (filters, servlets ...). This could be a problem if you are initializing things, in the standard server startup, which you are used later in Jawr. These elements could be missing. This is why we have added the parameter servletsToInitialize to be able to initialize other servlets, which you could initialize data used later by Jawr.
As the bundle processor simulate the server startup, the idea is to only initialize the Jawr component. So with the springConfigFiles parameter, we can choose exactly which beans must be instanciated, in order to initialize the Jawr component.
For Spring MCV, Jawr provides the JawrSpringController which generates the bundles and handles the request. By default, if you don't provide the spring configuration files to the bundle processor, it will search for the configuration file associated to your spring dispatcher servlet. For example:
<servlet> <servlet-name>dispatcher</servlet-name> <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class> <load-on-startup>1</load-on-startup> </servlet>
With the below configuration, the bundle processor will search for a configuration file named dispatcher-servlet.xml. Here dispatcher is the name of the servlet.
If in your spring MVC configuration file, you don't have only the JawrSpringController defined (which is generally the case), we advise you to create a separate file containing only the JawrSpringController declaration, and use the import tag to include it in your spring configuration. So in that case, you must pass as argument to the bundle processor the spring configuration file containing the JawrSpringController declaration.
If your controller use dynamic properties, you can define these dynamic properties in another file, and pass to the bundle processor, the files defining the properties and the JawrSpringController.
For example, if you have the following JawrSpringController declaration :
<!-- Base Jawr config --> <bean id="jawrJsController" class="net.jawr.web.servlet.JawrSpringController" > <!-- This must match the servlet-mapping to which the spring servlet is bound --> <property name="mapping" value="/spring/"/> <!-- This must match the controller mapping prefix to which the jawr controllers are bound at the urlMapping bean below --> <property name="controllerMapping" value="/jawrJS/"/> <property name="configuration"> <props> <prop key="jawr.gzip.on">{gzip.resource}</prop> </props> </property> <property name="configLocation" value="/jawr-springMVC.properties" /> </bean>
In the configuration above, you will notice that the "jawr.gzip.on" property is set with the value of "gzip.resource". If you have a such configuration, you will probably have the declaration of your property in another file. And in that case you will pass the file defining the gzip.resource property to the bundle processor, so the Jawr component initialization can be initialized properly.
One of the goals of this feature is to provide a better support for CDN. In the CDN directory, generated by the BundleProcessor, you will find all the bundles which are accessible in production and in debug modes.
To define the URL which will contain the Jawr bundles on the CDN, you must specify the context path, which should be used like below:
jawr.url.contextpath.override=http://myCDN.com/myApplication jawr.url.contextpath.ssl.override=https://myCDN.com/myApplication
It is also possible to use the resources files from the CDN even in debug mode using:
jawr.url.contextpath.override.used.in.debug.mode=true
As explained above, the bundle preprocessing use the predefined mapping described in the full mapping files. This means that in debug mode, if you update a resource file, which is already part of a bundle, the change will be taken in account.
BUT if you add a new resource file to a bundle mapping, this resource file will never been taken in account, unless you clean your working directory and start again your application.
Note also that, you could switch from debug mode to production mode, without launching the bundling process, but you have to keep in mind that the production bundles are the one which have been processed during the bundling phase. This means that if you have modified a resource file, since the latest bundling process, you will have to launch again the bundling process to have this updated resource file in your production bundle.


DEBDIFF(1) DEBDIFF(1) NAME debdiff - compare file lists in two Debian packages SYNOPSIS debdiff [options] debdiff [options] ... deb1 deb2 debdiff [options] ... changes1 changes2 debdiff [options] ... --from deb1a deb1b ... --to deb2a deb2b ... debdiff [options] ... dsc1 dsc2 DESCRIPTION debdiff takes the names of two Debian package files (.debs or .udebs) on the command line and compares their contents (considering only the files in the main package, not the maintenance scripts). It shows which files have been introduced and which removed between the two package files, and is therefore useful for spotting files which may have been inadvertently lost between revisions of the package. It also checks the file owners and permissions, and compares the control files of the two packages using the wdiff program. If no arguments are given, debdiff tries to compare the content of the current source directory with the last version of the package. debdiff can also handle changes between groups of .deb files in two ways. The first is to specify two .changes files. In this case, the .deb files listed in the .changes file will be compared, by taking the contents of all of the listed .deb files together. (The .deb files listed are assumed to be in the same directory as the .changes file.) The second way is to list the .deb files of interest specifically using the --from ... --to syntax. These both help if a package is broken up into smaller packages and one wishes to ensure that nothing is lost in the interim. debdiff examines the devscripts configuration files as described below. Command line options override the configuration file settings, though. If debdiff is passed two source packages (.dsc files) it will compare the contents of the source packages. If the source packages differ only in Debian revision number (that is, the .orig.tar.gz files are the same in the two .dsc files), then interdiff(1) will be used to compare the two patch files if this program is available on the system, otherwise a diff will be performed between the two source trees. OPTIONS --dirs, -d The default mode of operation is to ignore directory names which appear in the file list, but they, too, will be considered if this option is given. --nodirs Ignore directory names which appear in the file list. This is the default and it can be used to override a configuration file set‐ ting. --move FROM TO, -m FROM TO It sometimes occurs that various files or directories are moved around between revisions. This can be handled using this option. There are two arguments, the first giving the location of the directory or file in the first package, and the second in the sec‐ ond. Any files in the first listing whose names begin with the first argument are treated as having that substituted for the sec‐ ond argument when the file lists are compared. Any number of --move arguments may be given; they are processed in the order in which they appear. --move-regex FROM TO This is the same as --move, except that FROM is treated as a regu‐ lar expression and the perl substitution command s/^FROM/TO/ is applied to the files. In particular, TO can make use of backref‐ erences such as $1. --nocontrol debdiff will usually compare the respective control files of the packages using wdiff(1). This option suppresses this part of the processing. --control Compare the respective control files; this is the default, and it can be used to override a configuration file setting. --controlfiles FILE[,FILE ...] Specify which control files to compare; by default this is just control, but could include postinst, config and so on. Files will only be compared if they are present in both .debs being compared. The special value ALL compares all control files present in both packages, except for md5sums. This option can be used to override a configuration file setting. --wdiff-source-control When processing source packages, compare control files using wdiff. Equivalent to the --control option for binary packages. --no-wdiff-source-control Do not compare control files in source packages using wdfiff. This is the default. --wp, --wl, --wt Pass a -p, -l or -t option to wdiff respectively. (This yields the whole wdiff output rather than just the lines with any changes.) --show-moved If multiple .deb files are specified on the command line, either using .changes files or the --from/--to syntax, then this option will also show which files (if any) have moved between packages. (The package names are simply determined from the names of the .deb files.) --noshow-moved The default behaviour; can be used to override a configuration file setting. --renamed FROM TO If --show-moved is being used and a package has been renamed in the process, this command instructs debdiff to treat the package in the first list called FROM as if it were called TO. Multiple uses of this option are permitted. --exclude PATTERN Exclude files that match PATTERN. Multiple uses of this option are permitted. --diffstat Include the result of diffstat before the generated diff. --no-diffstat The default behaviour; can be used to override a configuration file setting. --auto-ver-sort When comparing source packages, do so in version order. --no-auto-ver-sort Compare source packages in the order they were passed on the com‐ mand-line, even if that means comparing a package with a higher version against one with a lower version. This is the default be‐ haviour. --unpack-tarballs When comparing source packages, also unpack tarballs found in the top level source directory to compare their contents along with the other files. This is the default behaviour. --no-unpack-tarballs Do not unpack tarballs inside source packages. --no-conf, --noconf Do not read any configuration files. This can only be used as the first option given on the command-line. --help, -h Show a summary of options. --version, -v Show version and copyright information. --quiet, -q Be quiet if no differences were found. --ignore-space, -w Ignore whitespace in diffs. CONFIGURATION VARIABLES The two configuration files /etc/devscripts.conf and ~/.devscripts are sourced by a shell in that order to set configuration variables. Command line options can be used to override configuration file settings. Envi‐ ronment variable settings are ignored for this purpose. The currently recognised variables are: DEBDIFF_DIRS If this is set to yes, then it is the same as the --dirs command line parameter being used. DEBDIFF_CONTROL If this is set to no, then it is the same as the --nocontrol com‐ mand line parameter being used. The default is yes. DEBDIFF_CONTROLFILES Which control files to compare, corresponding to the --con‐ trolfiles command line option. The default is control. DEBDIFF_SHOW_MOVED If this is set to yes, then it is the same as the --show-moved command line parameter being used. DEBDIFF_WDIFF_OPT This option will be passed to wdiff; it should be one of -p, -l or -t. DEBDIFF_SHOW_DIFFSTAT If this is set to yes, then it is the same as the --diffstat com‐ mand line parameter being used. DEBDIFF_WDIFF_SOURCE_CONTROL If this is set to yes, then it is the same as the --wdiff-source-control command line parameter being used. DEBDIFF_AUTO_VER_SORT If this is set to yes, then it is the same as the --auto-ver-sort command line parameter being used. DEBDIFF_UNPACK_TARBALLS If this is set to no, then it is the same as the --no-unpack-tar‐ balls command line parameter being used. EXIT VALUES Normally the exit value will be 0 if no differences are reported and 1 if any are reported. If there is some fatal error, the exit code will be 255. SEE ALSO dpkg-deb(1), wdiff(1), interdiff(1), diffstat(1) and devscripts.conf(5). AUTHOR debdiff was originally written as a shell script by Yann Dirson <dir‐<EMAIL_ADDRESS>and rewritten in Perl with many more features by Julian Gilbey<EMAIL_ADDRESS>The software may be freely redistributed under the terms and conditions of the GNU General Public License, version 2. DEBIAN Debian Utilities DEBDIFF(1)


cpgf script binding -- an open source library to connect Lua, Google V8 Javascript and Python to C++
cpgf script binding library is a very easy to use script binding engine to bind Lua, Google V8 Javascript and Python to C++.
The library uses reflection meta data extensively.
cpgf script binding is licensed under Apache License, Version 2.0
The supported Lua library is version 5.2 and 5.1
The supported Google V8 Javascript library is Version 3.4.5
The supported Python is version 2.7.3.
Key features
- Bind C++ class to Lua and Google V8 Javascript. Then Lua and Javascript can create instance, invoke class member function, get/set class field or property, and more.
- Bind C++ enum type to Lua and V8 Javascript. Then Lua and Javascript can access the enum value by name.
- Bind C++ functions (global or member) to Lua, V8, and Python.
- Bind C++ values to Lua, V8 and Python variable.
- Bind C++ operators to Lua (Lua only). The overloaded operators in C++ are bound to Lua together with the class.
- Invoke Lua, V8 Javascript and Python functions from C++.
- Get and set Lua, V8 Javascript and Python value from C++.
Different script language, same API interface!
Though there is very big difference in internal implementation and public API among Luam Google V8 Javascript and Python, cpgf makes the binding exactly the same.
We use same data, the reflection meta data, to drive the binding.
We use same API, only the interface of classes GScriptObject and IScriptObject, to make the binding.
What does that mean?
It means
write your C++ code once, binding to any script languages -- now supported Lua, V8 Javascript and Python, on any platforms -- Windows, Linux, Mac (iOS, iPhone, iPad), VC, gcc, XCode.
 Try this library. Use Lua, Javascript and Python to make your game AI and logic fast and easily.
Are you a desktop application developer? Try this library. Use Lua, Javascript and Python to extend your application fast and easily.
Are you a web developign team? Try this libray. Connect your great web experience to desktop fast and easily.
Limitations and problems in the script binding ending
- Script can't override C++ virtual functions. This may change in the future.
- Python binding may (or may not) have memory leaks. Even an empty Py_Intialize and Py_Finalize pair will cause memory leak so it's very difficult to hunt memory leak in the binding.


Allows to calculate Data Agreement Criterion (DAC) scores. This can be done to determine prior-data conflict or to evaluate and compare multiple priors, which can be experts' predictions. Bousquet (2008) <doi.org/10.1080/02664760802192981>.
| Version: | 0.1.1 |
| Depends: | R (≥ 3.5.0) |
| Imports: | blavaan, utils, stats, flexmix, sfsmisc, truncnorm |
| Published: | 2018-05-04 |
| Author: | Duco Veen [aut, cre], Naomi Schalken [aut], Rens van de Schoot [aut] |
| Maintainer: | Duco Veen <ducoveen at gmail.com> |
| License: | GPL-3 |
| NeedsCompilation: | no |
| CRAN checks: | DAC results |
| Reference manual: | DAC.pdf |
| Package source: | DAC_0.1.1.tar.gz |
| Windows binaries: | r-devel: DAC_0.1.1.zip, r-release: DAC_0.1.1.zip, r-oldrel: DAC_0.1.0.zip |
| OS X binaries: | r-release: DAC_0.1.1.tgz, r-oldrel: DAC_0.1.0.tgz |
| Old sources: | DAC archive |
Please use the canonical form https://CRAN.R-project.org/package=DAC to link to this page.


Deep Q-learning from Demonstrations
Paper: Download here
Authors: Todd Hester et. al
Published in: AAAI-18
In-depth Analysis: Daniel Sieta’s post
Takeaway message
Naively adding expert demonstration data to the replay buffer or pre-training an agent with this data does not offer benefits and sometimes can be detrimental. The combination of the supervised loss and the TD loss during pre-training is critical for the agent to learn a representation that is not rendered useless once training starts. During training the agent must continue using both the expert and the self-generated data using a prioritized experience replay. Demonstration data is used more as the number of iterations in the training phase increases. This is because the agent encounters new states in the game.
Motivations
Training DQN for real-world applications can be challenging as it requires huge amount of data. Accurate simulators aren’t available for many real-world tasks. The learning can be accelerated by using demonstration data to pre-train an agent so that it can perform well in the task from the start.
Proposed Solution
The agent was pre-trained using 4 losses using the demonstration data.
- Supervised loss: Large margin loss to push the expert’s actions over other actions.
- TD loss: To help the agent learn the value function. It also ensures that the network satisfies the Bellman equation.
- n-step (n=10) TD loss: To help propagate the values of expert’s trajectory to earlier states.
- L-2 regularization loss: To prevent the agent from overfitting to the demonstration data.
The large margin classifier forces the values of other actions to be at least a margin lower than the value of the expert’s action. This grounds the values of unseen actions to reasonable values and makes the greedy policy induced by the value function imitate the demonstrator.
During training, the demonstration data is never overwritten in the replay buffer. Sampling is done using a prioritized experience replay buffer which also decides the ratio between demonstration and self-generated data. The supervised loss is omitted during training.
Evaluation of the solution
Comparison was made between DQfD, Prioritized Duelling Double (PDD) DQN, and imitation learning. DQfD results in large boost in initial performance. It acheives SOTA performance in 11 Atari games. DQfD performs well in the hardest exploration games (Montezuma’s Revenge, Pitfall, Private Eye) where demonstration data is used instead of intelligent exploration.
Analysis of the problem, idea, and evaluation
The losses are designed to make the agent learn that other actions are less better than the expert action. So the goal is to create an agent that imitates the expert and the same time have a rough idea about the Q-values of the other states (unseen states) visited during the pre-training step.
Contributions
The paper presents a principled way to combine imitation learning with deep Q-learning as naive pre-training isn’t guaranteed to perform well.
Questions
- How is the regularization loss helpful while training the RL agent? Doesn’t it result in sub-optimal behavior?


---
layout: post
title: Aperture 2 Quick Tip - Nik Viveza For $119
tags:
- Aperture
- Apple Aperture
- Articles
- Nik Viveza
- Nikon
- Nikon Capture NX2
status: publish
type: post
published: true
meta:
_edit_lock: "1229607590"
_edit_last: "2"
dsq_thread_id: "370594415"
---
Just in time for the Holidays. Here is a really quick tip if you like and want Nik Viveza for Aperture but you don't like the $249.95 price tag. I bought the plug-in for Aperture when it came out because I was already familiar with it from Nikon Capture NX and NX2 (and I like to waste/spend money, actually I try to support companies with my purchases that I really really like). Here is the quick and cheap way to get it with a minor downside, the downside being the real reason that I sprung for the $249.95.
Nik Viveza if you are not familiar with it is about the coolest, quickest way to mask localized adjustments you have ever seen. If you can get used to it, Viveza is a huge time saver. Well here is the deal - it's pretty much built into Nikon Capture NX and NX2. Just grab a copy of the full version of Capture NX2 for one of the rediculously low sale prices of like $119 at Cameta Camera or somewhere else on the web. If you are really cheap you can probably find old versions of NX for even lower but heck at $119 - go with the current version. All you have to do is setup your external editor preferences in Aperture to be NX2 with a 16-bit Tiff and you are in business.
The downside is that if you use CS2/3/4 as an external editor as well you will have to switch your preferences back and forth. The real reason that I reluctantly came up with the $249.95. Hey I told you I am lazy.
RB


--- layout: post title: ! 'Bjarne Stroustrup: C++11 Style' published: true date: 2012-02-27 categories: [] posterous_url: http://blog.hungerandthirstdesign.com/bjarne-stroustrup-c11-style posterous_slug: bjarne-stroustrup-c11-style ---
Worth a watch.


Introduction
Test Result
| Result ID | Profile | Start time | End time | Benchmark | Benchmark version |
| xccdf_org.open-scap_testresult_test | test | 2014-01-19 13:59 | 2014-01-19 13:59 | embedded | 0.9 |
Target info
Targets
|
Addresses
|
Platforms
|
Score
| system | score | max | % | bar |
| urn:xccdf:scoring:default | 50.00 | 100.00 | 50.00% |
Results overview
Rule Results Summary
| pass | fixed | fail | error | not selected | not checked | not applicable | informational | unknown | total |
| 1 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 2 |
Rule results summary
| Title | Result |
| Prevent Log In to Accounts With Empty Password | fail |
| Verify All Account Password Hashes are Shadowed | pass |
Results details
Result for Prevent Log In to Accounts With Empty Password
Result: fail
Rule ID: no_empty_passwords
Time: 2014-01-19 13:59
Severity: high
If an account is configured for password authentication
but does not have an assigned password, it may be possible to log
into the account without authentication. Remove any instances of the nullok
option in /etc/pam.d/system-auth
to
prevent logins with empty passwords.
If an account has an empty password, anyone could log in and run commands with the privileges of that account. Accounts with empty passwords should never be used in operational environments.
Security identifiers
- CCE-27038-9
Remediation script
sed -i 's/\<nullok\>//g' /etc/pam.d/system-auth
Result for Verify All Account Password Hashes are Shadowed
Result: pass
Rule ID: no_hashes_outside_shadow
Time: 2014-01-19 13:59
Severity: medium
If any password hashes are stored in /etc/passwd
(in the second field,
instead of an x
), the cause of this misconfiguration should be
investigated. The account should have its password reset and the hash should be
properly stored, or the account should be deleted entirely.
The hashes for all user account passwords should be stored in
the file /etc/shadow
and never in /etc/passwd
,
which is readable by all users.
Security identifiers
- CCE-26476-2


Invdividuals and interactionsover processes and tools
Working softwareover comprehensive documentation
Customer collaborationover contract negotiation
Responding to changeover following a plan
That is, while there is value in the items on the right, we value items on the left more.
What is our objective?
Serve the Citizens?
Assist City Staff?
Align with Strategic Action Plan?
Obviously, but as developers, our goal is to produce QUALITY SOFTWARE.
How do we focus on the objective of quality software?
Customer engagement & involvement
Accountability
Minimizing impact of defects
Customer Interaction
Customer should be involved throughout project
Building requirements through user stories is a customer centric activity
Requirements are expected to change
Continuous Improvement
User Stories
Working with the customer to determine not just requirements, but also design
Deep dive into what the customer wants
Catch issues/concerns early
Get that crucial customer buy-in
Example User Story
As a Permitting Customer I need to be able to sign-in at the front desk,
so that
Permitting staff can assist me.
Success Criteria
Can enter name and reason for visit
Both fields are required
Dropdown for common reason choices
After submission, staff are notified of customer in queue
Breaking Story Into Tasks
Create Model for customer entry
Create Model for reason suggestions
Seed data for reason suggestions
Build interface for entering data
Build backend API for receiving data
Configure notifications
Project Estimation
Estimation is difficult
Current process is a best-guess effort
Not tracking our estimates
Better Estimates
Break User Stories into achievable tasks
Estimate effort, not time
Assign points to reflect amount of effort (e.g. 0, 1, 2, 3, 5, ...)
Group tasks into iterations
# of points finished in iteration = velocity
Iterations
Specific time interval. Same every time
Every iteration results in a deliverable piece of software
Using velocity we determine what features will fit in a iteration
Iterations & Deadlines
Meet deadline exactly? Awesome, onto the next.
Come in under the deadline? Good, recalculate velocity, onto the next.
Cut features or push deadline? Fine. Evaluate why, onto the next.
The key
They key is to constantly be reevaluating the tasks to see where they fit in the project. Tracking this gives us meaningful
data on what we're doing and how we can change to make it better.
Dealing With Defects
Issues found during an iteration are not defects. They are part and parcel of development. They are to be fixed immediately
and then they are done. Time spent tracking these is time lost focusing on the iteration.
Once a iteration is finished and a deliverable is out, any defects found or reported
must be tracked. These will often become new tasks or
stories that need to be evaluated.
Tracking Defects
Tracking defects that are found out-of-iteration is very important. They need to be carefully analyzed to determine why they
made it out of iteration. This is not negative tracking. It just means we can potentially learn from it and prevent
it during iterations in the future.
Code Review
At the end of every iteration, the team gets together to take stock of what was accomplished. Part of this is conducting
code reviews. Each developer will present and go over the code that is unique to their project. The focus here is to
evaluate the application specific bits of design and code for maintainability. Correctness should be already validated
via unit tests and code linting.


| hasOwnProperty readonly |
Reports whether a given property is defined with an instance or within the prototype chain. |
| isPrototypeOf readonly |
Checks whether the given object is a prototype of this object. |
| propertyIsEnumerable readonly |
Reports whether a given property is enumerable. |
| toLocaleString readonly |
Creates and returns a string representing this object, localized for the current locale. See?toString(). |
| toSource readonly |
Creates and returns a string representation of this object. |
| toString readonly |
Creates and returns a string representing this object. |
| unwatch readonly |
Removes the watch function of a property. |
| valueOf readonly |
Retrieves and returns the primitive value of this object. |
| watch readonly |
Adds a watch function to a property, which is called when the value changes. |


Göteborg Jazz Orchestra med Alexander Lövmark
Göteborg Jazz Orchestra ångar vidare på konceptet "Jazz är Kul!"...
CHOIR CLUB på Södra Teatern
This is a wider card with supporting text below as a natural lead-in to additional content. This content is a little bit longer.
Musik på Udden
This card has supporting text below as a natural lead-in to additional content.
Disney´s Beauty & the beast
This is a wider card with supporting text below as a natural lead-in to additional content...


Module scheduler
The Scheduler allows you to easily schedule functions for execution.
Under the hood it used minetest.register_on_globalstep to schedule functions.
Functions
| init () | Initializes the scheduler. |
| schedule (name, interval, run_function, overshoot_policy) | Schedules the given function. |
| step (since_last_call) | The step function that is registered with minetest.register_on_globalstep. |
| unschedule (name) | Unschedules/Removes the function with the given name. |
Tables
| immediate_functions | The table of functions for immediate execution. |
Fields
| OVERSHOOT_POLICY_CATCH_UP | If more time has elapsed than the interval of the scheduled function, the function will be run as many times as necessary to catch up. |
| OVERSHOOT_POLICY_RUN_ONCE | If more time has elpased than the interval of the scheduled function, the function will still only be run once. |
| initialized | If the scheduler has been initialized. |
Functions
- init ()
-
Initializes the scheduler.
Note that the client should never need to call this function.
- schedule (name, interval, run_function, overshoot_policy)
-
Schedules the given function.
Parameters:
- name The name of the function.
- interval The interval in which to run the function. A value of zero will make the function run on every global step, the overshoot policy will have no effect in that case.
- run_function The function to execute.
- overshoot_policy Optional. The overshoot policy. Defaults to scheduler.OVERSHOOT_POLICY_RUN_ONCE.
- step (since_last_call)
-
The step function that is registered with minetest.register_on_globalstep.
Note that the client should never call this function as it might mess up the scheduled functions.
Parameters:
- since_last_call The elapsed time since the last call.
- unschedule (name)
-
Unschedules/Removes the function with the given name.
Parameters:
- name The name of the function to unschedule.
Tables
Fields
- OVERSHOOT_POLICY_CATCH_UP
- If more time has elapsed than the interval of the scheduled function, the function will be run as many times as necessary to catch up.
- OVERSHOOT_POLICY_RUN_ONCE
- If more time has elpased than the interval of the scheduled function, the function will still only be run once.
- initialized
- If the scheduler has been initialized.


Jets lose control of promotion push
TEAM JETS must now rely on favours from elsewhere if they are to secure an immediate return to national netball, after suffering their second defeat of the campaign.
by Jason FoxThe Caesareans finished 57-49 down at the hands of Team Bath A on Saturday – disrupting their chase for the sole promotion play-off berth in South West Regional League Division I.
They did recover to beat strugglers Whitchurch 48-36, but they remain three points behind unbeaten leaders Aquarians at the midway point of the season, having already lost to (and played a game more than) their title rivals.
Coach Linda Andrews said: ‘The Whitchurch game ... it was so important to come out with a win and restore the faith, because the loss was hard to take.
‘Whether it [the Bath defeat] is costly or not, we don’t know. We just need people to beat Aquarians now and there are teams who are more than capable of doing that if they’ve got their strongest team out.'
Jets and Bath were tied at 13-13 and 27-27 at the end of the first two periods, before the latter edged their noses in front at 40-43.
Jets pulled back to 46 apiece before a lack of concentration proved the difference.
‘There were four silly mistakes,’ Andrews explained.
‘We could have won it. When you’re playing against a team that’s as good as you it’s important to make those clinical decisions when under pressure. That’s what let us down and it was only six minutes in the last quarter that lost us the game.’
In a similar fashion to Saturday’s game, Jets and Whitchurch were level at 11-11 and 21-21 at the end of Q1 and Q2 respectively, before Jets hammered home the importance of accuracy when feeding the circle.
Interceptions galore quickly gave the Islanders the advantage, with a 16-5 third-quarter score deflating the Whitchurch squad.
Andrews added: ‘In the third quarter Molly Carré had an absolute stormer.
‘Our defensive end took six interceptions, which we managed to get to the shooters and they converted. That gave us a bit of a break.'
More in Monday's JEP.


Troop Meeting Plan Template
Troop Letterhead
Leadership Position Application
Leadership Position Descriptions
Annual Health & Medical Record
Activity Consent Form
Flight Consent Form
Packing for Summer Camp
Packing for Warm Weather Camping?
Packing for Cold Weather Camping?
Packing for a Backpacking Trip?
Do We Eat on a Backpacking Trip?
Menu Ideas
Spirit Form
Merit Badge Counselor List By Counselor
Merit Badge Counselor List By Badge
Merit Badge Requirements
Scout Requirements
Tenderfoot Requirements
2nd Class Requirements
1st Class Requirements
Star Requirements
Life Requirements
Eagle Project Help
Eagle Requirements
Eagle Scout Leadership Project Workbook
Eagle Scout Application
Eagle Palm Requirements
Eagle Palm Application
Adult Volunteer Application
Merit Badge Counselor Application


Oops! Something went wrong while communicating with Shopify servers.
Please retry the installation using the button below. If the issue persists, please let us know at info@digismoothie.com.


The routines documented here compute the discrete Fourier transform (DFT) of a sequence of complex numbers in either single or double precision arithmetic. The DFT is computed using a highly-efficient FFT algorithm. There are two sets of interfaces available: simple drivers and expert drivers. The simple drivers perform in-place transforms on data held contiguously in memory using a fixed scaling factor; these are simpler to use and are sufficient for many problems. The expert drivers offer greater flexibility by including a number of additional arguments. These allow you to control: the scaling factor applied; whether the result should be output to a separate vector; and, the increments used in storing successive elements of both the input sequence and the result.


How does a galaxy's morphology change with wavelength?
In Galaxy Zoo 1 and 2 we showed you images of galaxies taken by the Sloan Digital Sky Survey (SDSS). These images
combine information from 3 (g, r, i) of the 5 observational filters used by Sloan (u, g, r, i, z) to produce a single colour image for
each galaxy. Each of the 5 filters observe the galaxy at different wavelengths, with the u-band more sensitive to hot
young stars at shorter wavelengths, through to the z-band being more sensitive to cooler, older populations of stars at
longer wavelengths. The 5 Sloan filters and their wavelengths are shown in Figure 1.
Figure 1: The five SDSS filters and the wavelengths they span.
With each of the 5 filters gathering light from different populations of stars, we are interested in seeing
how a galaxy's morphological classification may differ across each of the filters individually. For example, do spiral arms containing young stars become more prominent in bluer bands? And do bulges in spiral galaxies, which tend to be formed of older stars, look bigger in redder bands? To investigate these, and many other morphological properties, we take a sample
of 1000 SDSS imaged galaxies and split their combined colour image back down into the original 5 single filter images
(see Figure 2). These monochromatic images are then put into Galaxy Zoo, and with your continued help classifying, we
hope to answer our original question soon!
Figure 2. Example postage stamps of the monochromatic single filter images.


| Subject Code | Subject | Semester | Credit | Assigned Lecturers | |||
|---|---|---|---|---|---|---|---|
| {{subject.subjectCode}} | {{subject.subjectTitle}} | {{subject.semester}} | {{subject.credit}} |
|
edit delete | ||
| {{subject.subjectCode}} | {{subject.subjectTitle}} | {{subject.year}} | {{subject.semester}} | {{subject.credit}} |
|
edit delete | |
| {{subject.subjectCode}} | {{subject.subjectTitle}} | {{subject.year}} | {{subject.semester}} | {{subject.credit}} |
|
edit delete | |
| {{subject.subjectCode}} | {{subject.subjectTitle}} | {{subject.year}} | {{subject.semester}} | {{subject.credit}} |
|
edit delete |