This is a simple page Angular app with a navigation through tabs which simulates a registration.
At this stage you can start the process.
In the next tab you can fill in some data in a form and test for certain attributes
The confirmation tab will shoe you all the fields you have filled in for a last confirmation
The last tab is a simple "All is done" and it will automatically reset the data.
In a perfect world it would have sent the data to a backend server...


Books Shelves
home
Categories
All
History
Horror
Fantacy
Kids
Favorite
Shelves
Exchange
Users' Books
about
Users' Books


Now our web component has a property that can be changed and is updated on the page.
document.querySelector("say-hello").to = "THAT Conference"


Are car subscriptions worth it? Let’s Talk About #12
by Rory LeeCar subscription services are on the rise in Malaysia. But, with so many different versions from different operators, the question becomes: Is it worth it? Is it better than buying outright? Alex and Amin discuss.


?01497626
7
ft
o
m
'
¡
a
lu
The
New
York
copyright
reserved
botanical
Garden
PLANTS
OF
THE
WEST
INDIES
GRENADA
Forestieria
rhamnifolia
Griseb.
Tree
of
25*È
d.b.h.
;
frait
blue,
glaua^us.
Coastal
dry
area
forest,
River
Sallee
area.
R.A.
&
E.S.
Howard
187^2
March
4-10,
1979
BOTANICAL
GARDE**,
01497626
Legend -
Level of confidence that token is an accurately-transcribed word
extremely low
very low
low
undetermined
medium
high
very high


Adjust saturation of RGB images.
tf.compat.v1.image.adjust_saturation
tf.compat.v2.image.adjust_saturation
tf.image.adjust_saturation( image, saturation_factor, name=None )
This is a convenience method that converts RGB images to float representation, converts them to HSV, add an offset to the saturation channel, converts back to RGB and then back to the original data type. If several adjustments are chained it is advisable to minimize the number of redundant conversions.
image
is an RGB image or images. The image saturation is adjusted by
converting the images to HSV and multiplying the saturation (S) channel by
saturation_factor
and clipping. The images are then converted back to RGB.
image
: RGB image or images. Size of the last dimension must be 3.saturation_factor
: float. Factor to multiply the saturation by.name
: A name for this operation (optional).Adjusted image(s), same shape and DType as image
.
>> import tensorflow as tf >> x = tf.random.normal(shape=(256, 256, 3)) >> tf.image.adjust_saturation(x, 0.5)
InvalidArgumentError
: input must have 3 channels


{% extends "/survey/fields/edit.html" %} {%block title%}Edit Check Field{%endblock%} {%block content%}
*You can put any valid font-awesome icon (just omit the "icon-" part). See here for a complete list of all possible icons. Have fun


Reproduced with permission of the authors.
Copyright 2012 Marty Stepp, Jessica Miller, and Victoria Kirst.
All rights reserved.
Further reproduction or distribution is prohibited without written permission.
this.fieldName// access field
this.fieldName = value; // modify field
this.methodName(parameters); // call method
all JavaScript code actually runs inside of an object
by default, code runs in the global window object (so this === window)
all global variables and functions you declare become part of window
the this keyword refers to the current object
Event handler binding
window.onload = function() {
$("textbox").observe("mouseout", booyah);// bound to text box here$("submit").observe("click", booyah);// bound to submit button here
};
function booyah() { // booyah knows what object it was called onthis.value = "booyah";
}
event handlers attached unobtrusively are bound to the element
inside the handler, that element becomes this (rather than the window)
function processDucks() {
if ($("huey").checked) {
alert("Huey is checked!");
} else if ($("dewey").checked) {
alert("Dewey is checked!");
} else {
alert("Louie is checked!");
}alert(this.value + " is checked!");
}
if the same function is assigned to multiple elements, each gets its own bound copy
function delayMsg() {
setTimeout(booyah, 5000);
document.getElementById("output").innerHTML = "Wait for it...";
}
function booyah() { // called when the timer goes off
document.getElementById("output").innerHTML = "BOOYAH!";
}
setInterval example
var timer = null;// stores ID of interval timer
function delayMsg2() {
if (timer == null) {
timer = setInterval(rudy, 1000);
} else {
clearInterval(timer);
timer = null;
}
}
function rudy() { // called each time the timer goes off
document.getElementById("output").innerHTML += " Rudy!";
}
Passing parameters to timers
function delayedMultiply() {
// 6 and 7 are passed to multiply when timer goes off
setTimeout(multiply, 2000, 6, 7);
}
function multiply(a, b) {
alert(a * b);
}
any parameters after the delay are eventually passed to the timer function
doesn't work in IE6; must create an intermediate function to pass the parameters
why not just write this?
setTimeout(multiply(6 * 7), 2000);
Common timer errors
many students mistakenly write () when passing the function


Logging Components
Introduction
The client libraries never use logging to report errors, but logging can be enabled to help troubleshoot problems when the last error message does not provide a good enough indication of the root cause.
In general, we abide by the following principles:
- Logging should be controlled by the application developer. Unless explicitly instructed, the libraries produce no output to the console, except to emit a message to
std::clog
immediately before aGCP_LOG(FATAL)
terminates the process. - Logging should have very low cost:
- It should be possible to disable logs at compile time. They should disappear as-if there were
#ifdef
/#endif
directives around them. - A log line at a disabled log level should be about as expensive as an extra
if()
statement. At the very least it should not incur additional memory allocations or locks.
- It should be possible to disable logs at compile time. They should disappear as-if there were
- It should be easy to log complex objects.
- The logging framework should play well with the C++ iostream classes.
- The application should be able to intercept log records and re-direct them to their own logging framework.
Enabling logs
The application needs to do two things to enable logging:
- First, to configure the destination of the logs you must add a backend (see AddBackend) to the default LogSink.
- Second, you must configure what gets logged. Typically, you initialize the
*Connection
object with a TracingComponentsOption. Consult the documentation for each*Client
class to find what tracing components are available.
At run-time, setting the GOOGLE_CLOUD_CPP_ENABLE_CLOG
to a non-empty value configures a LogBackend that uses std::clog
. Likewise, setting the GOOGLE_CLOUD_CPP_ENABLE_TRACING=a,b
will enable tracing for components a
and b
across all client objects. The most common components are auth
, rpc
, and rpc-streams
.
Note that while std::clog
is buffered, the framework will flush any log message at severity WARNING
or higher.
Example: Logging From Library
Use the GCP_LOG()
macro to log from a Google Cloud Platform C++ library:
void LibraryCode(ComplexThing const& thing) {
GCP_LOG(INFO) << "I am here";
if (thing.is_bad()) {
GCP_LOG(ERROR) << "Poor thing is bad: " << thing;
}
}
Example: Enable Logs to std::clog
To enable logs to std::clog
the application can call:
void AppCode() {
google::cloud::LogSink::EnableStdClog();
}
As previously noted, this can be switched at run-time using the GOOGLE_CLOUD_CPP_ENABLE_CLOG
environment variable.


Samuel Butta
Software engineer, science and technology enthusiast.
I work a on cloud application called Intelligent Track and Trace based on microservice architecture.
I worked with big data technologies such as Flink, Spark, Hadoop or HBase on fulltext search engine.
I developed and maintained of large enterprise applications based on Java technologies or Scala for companies such as O2, Erste Group, Sazka, KKCG or Porsche.
I was part of a team developing web applications based on PHP/Nette framework.
My passion is good green tea. I am interested in physics, artificial intelligence and I am fascinated by math and logic.
Occasional floorball player, what I enjoy above all is quality time spent with my closest friends and family.


{% extends "skeleton.html" %} {% block title %}Downloads{% endblock %} {% block content %}
To get the latest development release of Apache Sling, you can check out the Source Code and Getting and Building Sling yourself. Otherwise, the releases below are available for download. To install, just download and extract. The PGP keys at https://people.apache.org/keys/group/sling.asc can be used to verify the integrity of the release archives.
All Apache Sling products are distributed under the terms of The Apache Software License (version 2.0). See our license, or the LICENSE file included in each distribution.
Use the links below to download binary or source distributions of Apache Sling from one of our mirrors.
You are currently using [preferred]. If you encounter a problem with this mirror, please select another mirror. If all mirrors are failing, there are backup mirrors (at the end of the mirrors list) that should be available. If the mirror displayed above is labeled preferred, then please reload this page by clicking here.
For quick provisioning using docker you can simply run docker pull apachesling/sling
to get access to the latest version of the launchpad.
To get the latest code you can build Sling yourself, it's not that hard.
If you are looking for previous releases of Apache Sling, have a look in the archives. For previous incubator releases of Apache Sling, have a look in the Incubator archives.
If you want to install the convenience binaries for the IDE tooling, it's recommended that you add [preferred]sling/eclipse as an update site URL. This way you will receive updates every time a new version is released. For specific versions and zipped update site download, see the table below.
{{ ide|markdown }}


Julia Package Ecosystem Pulse
Last updated 2016-03-17
Total number of packages by Julia version
* Showing only packages with at least one tagged version in METADATA.jl
METADATA changes in last 7 days
31 new, 54 updated
Stars
"Stars" are something you can give a package on Github. This plot is the total number of stars across all packages.
Top twenty all-time with 14-day change
| Gadfly | 848 | 14 |
| IJulia | 847 | 8 |
| Mocha | 631 | 10 |
| DataFrames | 263 | 4 |
| PyCall | 245 | 4 |
| JuMP | 222 | 5 |
| DSGE | 186 | 5 |
| Escher | 170 | 3 |
| Optim | 163 | 4 |
| Distributions | 161 | 4 |
| Convex | 134 | 6 |
| Morsel | 131 | 0 |
| Interact | 125 | 3 |
| Graphs | 122 | 3 |
| ParallelAccelerator | 117 | 10 |
| Winston | 113 | 2 |
| MXNet | 112 | 6 |
| GLM | 106 | 2 |
| PyPlot | 102 | 4 |
| GeneticAlgorithms | 98 | 1 |
Top twenty 14-day change with total
| ControlSystems | 18 | 18 |
| Gadfly | 14 | 848 |
| PlotlyJS | 13 | 13 |
| Mocha | 10 | 631 |
| ParallelAccelerator | 10 | 117 |
| IJulia | 8 | 847 |
| Maker | 8 | 8 |
| Convex | 6 | 134 |
| GLVisualize | 6 | 44 |
| MXNet | 6 | 112 |
| Plots | 6 | 64 |
| DSGE | 5 | 186 |
| GR | 5 | 20 |
| HPAT | 5 | 5 |
| JuMP | 5 | 222 |
| BuildExecutable | 4 | 29 |
| DataFrames | 4 | 263 |
| DiscriminantAnalysis | 4 | 4 |
| Distributions | 4 | 161 |
| HTSLIB | 4 | 12 |
Testing status changes
| Version | Tests pass | Tests fail | No tests | Package untestable | Total |
| Julia 0.3 | 463 (67%) | 74 (11%) | 89 (13%) | 63 (9%) | 689 |
| Julia 0.4 | 570 (65%) | 163 (19%) | 71 (8%) | 74 (8%) | 878 |
| Julia 0.5 | 414 (47%) | 317 (36%) | 72 (8%) | 74 (8%) | 877 |
Julia 0.4
20160317- AWSSDB: new → tests_fail.
- AstroLib: new → tests_pass.
- CDDLib: new → tests_fail.
- CQL: new → tests_fail.
- Celeste: new → tests_fail.
- ConicNonlinearBridge: new → tests_pass.
- ControlSystems: new → tests_pass.
- DifferentialDynamicProgramming: new → tests_pass.
- DiscriminantAnalysis: new → tests_pass.
- EEG: tests_fail → tests_pass.
- EllipticFEM: new → tests_pass.
- FastCombinations: new → tests_pass.
- HPAT: new → tests_fail.
- ICOADSDict: new → tests_pass.
- ImageView: tests_pass → tests_fail.
- JuMPeR: tests_pass → tests_fail.
- Mads: tests_fail → tests_pass.
- Maker: new → tests_pass.
- MarketData: tests_pass → tests_fail.
- MathToolkit: new → tests_pass.
- MuKanren: new → tests_pass.
- NetworkViz: new → tests_pass.
- PGFPlots: tests_pass → tests_fail.
- Pages: new → tests_pass.
- PlotlyJS: new → tests_pass.
- Polyhedra: new → tests_fail.
- PyLCM: new → tests_fail.
- QRupdate: new → tests_pass.
- ScikitLearn: new → tests_fail.
- ScikitLearnBase: new → no_tests.
- Shoco: new → tests_pass.
- SignalView: new → tests_fail.
- Spectra: new → tests_pass.
- StringInterpolation: new → tests_pass.
- Swifter: new → tests_pass.
- SymPy: tests_pass → tests_fail.
- TimeZones: tests_pass → tests_fail.
- TypedTables: new → tests_pass.
- VegaLite: new → tests_pass.
- AWSCore: tests_fail → not_possible.
- AWSEC2: tests_fail → not_possible.
- AWSIAM: tests_fail → not_possible.
- AWSLambda: tests_fail → not_possible.
- AWSS3: tests_fail → not_possible.
- AWSSES: new → tests_pass.
- AWSSNS: tests_fail → not_possible.
- AWSSQS: tests_fail → not_possible.
- BiomolecularStructures: tests_pass → tests_fail.
- Deldir: new → tests_pass.
- DustExtinction: tests_fail → tests_pass.
- ExperimentalAnalysis: new → tests_pass.
- FastTransforms: new → tests_pass.
- GaussianMixtureTest: new → tests_pass.
- GnuTLS: tests_pass → tests_fail.
- HTSLIB: new → tests_pass.
- HTTPClient: tests_fail → tests_pass.
- Hecke: new → tests_pass.
- JPLEphemeris: no_tests → tests_pass.
- KrylovMethods: new → tests_fail.
- LibCURL: tests_fail → tests_pass.
- MLDataUtils: new → tests_pass.
- MXNet: tests_fail → tests_pass.
- MeshIO: tests_fail → tests_pass.
- OpenDSSDirect: new → tests_fail.
- ParSpMatVec: new → tests_pass.
- PathDistribution: new → tests_pass.
- PatternDispatch: no_tests → tests_pass.
- Phonetics: new → tests_pass.
- PlanOut: new → tests_pass.
- RangeArrays: new → tests_pass.
- Reactive: tests_fail → tests_pass.
- ReverseDiffSource: tests_fail → tests_pass.
- RingArrays: new → tests_pass.
- Robotlib: new → tests_fail.
- RobustPmap: new → tests_pass.
- StringEncodings: new → tests_pass.
- TrafficAssignment: tests_fail → tests_pass.
- TravelingSalesmanHeuristics: new → tests_pass.
- XMLDict: tests_fail → tests_pass.
- Actors: new → tests_pass.
- Anasol: tests_fail → tests_pass.
- DustExtinction: tests_pass → tests_fail.
- DynamicDiscreteModels: new → tests_pass.
- EEG: tests_pass → tests_fail.
- FixedPointNumbers: tests_pass → tests_fail.
- GenericSVD: new → tests_pass.
- Gunrock: new → tests_fail.
- HTTPClient: tests_pass → tests_fail.
- HiddenMarkovModels: new → tests_pass.
- ISPC: new → tests_pass.
- LibCURL: tests_pass → tests_fail.
- MXNet: tests_pass → tests_fail.
- OpenFOAM: new → tests_fail.
- ParserCombinator: tests_fail → tests_pass.
- ProgressiveAligner: new → tests_pass.
- ReusableFunctions: tests_fail → tests_pass.
- ReverseDiffSource: tests_pass → tests_fail.
- Voronoi: new → tests_pass.
- WCS: new → tests_fail.
Julia 0.5
20160317- AWSSDB: new → tests_fail.
- AndorSIF: tests_fail → tests_pass.
- AstroLib: new → tests_pass.
- BiomolecularStructures: tests_pass → tests_fail.
- CDDLib: new → tests_fail.
- CQL: new → tests_fail.
- CSV: tests_fail → tests_pass.
- Cbc: tests_pass → tests_fail.
- Celeste: new → tests_fail.
- Cliffords: tests_fail → tests_pass.
- ClusterDicts: tests_fail → tests_pass.
- CoinOptServices: tests_pass → tests_fail.
- Color: tests_fail → tests_pass.
- ConicNonlinearBridge: new → tests_pass.
- ControlSystems: new → tests_fail.
- Currencies: tests_fail → tests_pass.
- DateParser: tests_fail → tests_pass.
- DifferentialDynamicProgramming: new → tests_pass.
- DiscriminantAnalysis: new → tests_fail.
- EllipticFEM: new → tests_fail.
- FaceDatasets: tests_fail → tests_pass.
- FastCombinations: new → tests_fail.
- FastaIO: tests_fail → tests_pass.
- FlexibleArrays: tests_fail → tests_pass.
- Gettext: tests_pass → tests_fail.
- HPAT: new → tests_fail.
- HTTPClient: tests_fail → tests_pass.
- ICOADSDict: new → tests_pass.
- ImageMagick: tests_fail → tests_pass.
- ImagineFormat: tests_fail → tests_pass.
- Interpolations: tests_pass → tests_fail.
- IntervalTrees: tests_fail → tests_pass.
- JPLEphemeris: tests_fail → tests_pass.
- Jags: tests_fail → tests_pass.
- JuMP: tests_pass → tests_fail.
- JuMPeR: tests_pass → tests_fail.
- LaTeX: tests_fail → tests_pass.
- Lexicon: tests_fail → tests_pass.
- LightGraphs: tests_pass → tests_fail.
- Loess: tests_fail → tests_pass.
- Maker: new → tests_fail.
- MarketData: tests_pass → tests_fail.
- MathToolkit: new → tests_pass.
- MatrixNetworks: tests_fail → tests_pass.
- Mocha: tests_fail → tests_pass.
- MsgPack: tests_fail → tests_pass.
- NRRD: tests_fail → tests_pass.
- Netpbm: tests_fail → tests_pass.
- NetworkViz: new → tests_fail.
- Pages: new → tests_pass.
- ParserCombinator: tests_fail → tests_pass.
- Patchwork: tests_fail → tests_pass.
- PlotlyJS: new → tests_fail.
- Polyhedra: new → tests_fail.
- PyCall: tests_pass → tests_fail.
- PyLCM: new → tests_fail.
- QRupdate: new → tests_pass.
- RobustShortestPath: tests_pass → tests_fail.
- ScikitLearn: new → tests_fail.
- ScikitLearnBase: new → no_tests.
- SerialPorts: tests_pass → tests_fail.
- Shoco: new → tests_pass.
- SignalView: new → tests_fail.
- Spectra: new → tests_pass.
- Stan: tests_fail → tests_pass.
- StatefulIterators: tests_fail → tests_pass.
- StringInterpolation: new → tests_pass.
- Swifter: new → tests_pass.
- TaylorSeries: tests_pass → tests_fail.
- TestImages: tests_fail → tests_pass.
- TikzGraphs: tests_pass → tests_fail.
- TypedTables: new → tests_pass.
- VLFeat: tests_fail → tests_pass.
- Vega: tests_fail → tests_pass.
- VegaLite: new → tests_pass.
- Wavelets: tests_fail → tests_pass.
- WoodburyMatrices: tests_pass → tests_fail.
- AWSCore: tests_fail → not_possible.
- AWSEC2: tests_fail → not_possible.
- AWSIAM: tests_fail → not_possible.
- AWSLambda: tests_fail → not_possible.
- AWSS3: tests_fail → not_possible.
- AWSSES: new → tests_pass.
- AWSSNS: tests_fail → not_possible.
- AWSSQS: tests_fail → not_possible.
- AndorSIF: tests_pass → tests_fail.
- Atom: tests_pass → tests_fail.
- BiomolecularStructures: tests_fail → tests_pass.
- CSV: tests_pass → tests_fail.
- Chipmunk: tests_pass → tests_fail.
- Cliffords: tests_pass → tests_fail.
- ClusterDicts: tests_pass → tests_fail.
- CoinOptServices: tests_fail → tests_pass.
- Color: tests_pass → tests_fail.
- ColorTypes: tests_fail → tests_pass.
- DateParser: tests_pass → tests_fail.
- DecisionTree: tests_pass → tests_fail.
- Deldir: new → tests_pass.
- Distributions: tests_pass → tests_fail.
- Diversity: tests_fail → tests_pass.
- Elly: tests_fail → tests_pass.
- ExcelReaders: tests_pass → tests_fail.
- ExperimentalAnalysis: new → tests_fail.
- FITSIO: tests_fail → tests_pass.
- FaceDatasets: tests_pass → tests_fail.
- FactCheck: tests_fail → tests_pass.
- FastTransforms: new → tests_pass.
- FastaIO: tests_pass → tests_fail.
- FlexibleArrays: tests_pass → tests_fail.
- ForwardDiff: tests_fail → tests_pass.
- GaussianMixtureTest: new → tests_pass.
- GitHub: tests_fail → tests_pass.
- HTSLIB: new → tests_pass.
- Hecke: new → tests_fail.
- HttpServer: tests_fail → tests_pass.
- ImageMagick: tests_pass → tests_fail.
- ImagineFormat: tests_pass → tests_fail.
- IntervalTrees: tests_pass → tests_fail.
- Ipopt: tests_fail → tests_pass.
- IterativeSolvers: tests_fail → tests_pass.
- JPLEphemeris: no_tests → tests_fail.
- Jags: tests_pass → tests_fail.
- JuMP: tests_fail → tests_pass.
- KrylovMethods: new → tests_fail.
- LaTeX: tests_pass → tests_fail.
- Lexicon: tests_pass → tests_fail.
- LibCURL: tests_fail → tests_pass.
- LibExpat: tests_fail → tests_pass.
- Lint: tests_pass → tests_fail.
- Loess: tests_pass → tests_fail.
- MLDataUtils: new → tests_pass.
- MathProgBase: tests_fail → tests_pass.
- MatrixDepot: tests_fail → tests_pass.
- MeshIO: tests_fail → tests_pass.
- MsgPack: tests_pass → tests_fail.
- MultiPoly: tests_fail → tests_pass.
- MultivariateStats: tests_fail → tests_pass.
- NRRD: tests_pass → tests_fail.
- Nemo: new → tests_fail.
- NetCDF: tests_fail → tests_pass.
- Netpbm: tests_pass → tests_fail.
- NumericFuns: tests_pass → tests_fail.
- OpenDSSDirect: new → tests_fail.
- Orchestra: tests_pass → tests_fail.
- PGFPlots: tests_pass → tests_fail.
- ParSpMatVec: new → tests_pass.
- ParserCombinator: tests_pass → tests_fail.
- Patchwork: tests_pass → tests_fail.
- PathDistribution: new → tests_pass.
- PatternDispatch: no_tests → tests_fail.
- PerceptualColourMaps: tests_pass → tests_fail.
- Phonetics: new → tests_pass.
- PlanOut: new → tests_pass.
- RangeArrays: new → tests_pass.
- Requests: tests_fail → tests_pass.
- Rif: tests_pass → tests_fail.
- RingArrays: new → tests_pass.
- Robotlib: new → tests_fail.
- RobustPmap: new → tests_pass.
- Roots: tests_fail → tests_pass.
- SFML: tests_pass → tests_fail.
- SQLite: tests_pass → tests_fail.
- Stan: tests_pass → tests_fail.
- StatefulIterators: tests_pass → tests_fail.
- StringEncodings: new → tests_pass.
- TestImages: tests_pass → tests_fail.
- TravelingSalesmanHeuristics: new → tests_pass.
- VLFeat: tests_pass → tests_fail.
- ValueOrientedRiskManagementInsurance: tests_pass → tests_fail.
- Vega: tests_pass → tests_fail.
- WaveletMatrices: tests_pass → tests_fail.
- Wavelets: tests_pass → tests_fail.
- XMLDict: tests_fail → tests_pass.
- Actors: new → tests_pass.
- Anasol: tests_fail → tests_pass.
- DynamicDiscreteModels: new → tests_pass.
- GenericSVD: new → tests_pass.
- GnuTLS: tests_pass → tests_fail.
- Gunrock: new → tests_fail.
- HTTPClient: tests_pass → tests_fail.
- HiddenMarkovModels: new → tests_fail.
- ISPC: new → tests_pass.
- LibCURL: tests_pass → tests_fail.
- Mocking: tests_fail → tests_pass.
- NLsolve: tests_fail → tests_pass.
- OpenFOAM: new → tests_fail.
- ParserCombinator: tests_fail → tests_pass.
- PyCall: tests_fail → tests_pass.
- ReusableFunctions: tests_fail → tests_pass.
- Voronoi: new → tests_pass.
- WCS: new → tests_fail.


--- layout: archive title: Zulip Chat Archive permalink: /stream/218272-FoMM-/-Lean-Together-2020/topic/travel.20and.20hotel.html ---
The official conference hotel is the Wyndham Pittsburgh University Center. Note that there are a couple other Wyndhams in Pittsburgh, so the University Center part is important! If CMU booked a hotel for you, this is where you're staying.
The Wyndham is about an hour by bus from the airport -- take the 28X to Forbes and Bigelow, and walk to the other side of the giant evil-looking tower. I think you can get a ConnectCard at the airport to pay for the buses with stored value. It's probably worth it if you expect to take the bus more than just to/from the airport. If you pay cash, the bus drivers can't make change for you, which is annoying, so get some one dollar bills at the airport. There are also taxis, Lyft, Uber, etc, which will take 30-60 minutes depending on traffic and cost $40-60.
I think a fair number of people are arriving Sunday evening, so maybe you could coordinate shared rides.
The conference is in Baker Hall A51. It's a ~15 minute walk from the hotel. Baker Hall and Porter Hall are the same building, so you can enter into either. The CMU campus topography is a little confusing, we'll try to put up signs in Porter/Baker. wyndham-baker.png
About traveling, it's probably a good time to remember to ask for an ESTA authorization if needed.
Yes, if you need an ESTA and you haven't done it yet, don't wait any longer!
These things used to be issued in just a few minutes but there's a warning on the website now saying that it can take several days
Also, if CMU was supposed to book the hotel for you and you can't find the confirmation email, search for mail from Mary Grace Joseph. Apparently the emails don't contain the name "Wyndham" in text anywhere.
Mine contains the word Wyndham.
Note that ESTAs are valid for two years; you can check on their website if yours is still valid
I think a fair number of people are arriving Sunday evening, so maybe you could coordinate shared rides.
In case people are too polite to spam this chat with arrival times, let's try this quick spreadsheet: https://docs.google.com/spreadsheets/d/1nHH6RaKgz-HZxtUlvSgfLc2aMrgdhyvs2M975qU_JRQ/edit?usp=sharing
It seems like there may have been a miscommunication with the hotel about payments from CMU. If you were told your hotel room was booked and paid for: don't worry, it still is. The hotel might ask for a credit card to make a deposit or something. This is fine, you won't be charged, things will be resolved soon, but apparently there's nobody working at the hotel over the weekend who has the power to resolve this...
Sorry for the confusion. Hopefully you won't notice anything, and everything will be resolved soon enough. Just a warning there might be a hiccup.
In case people are too polite to spam this chat with arrival times, let's try this quick spreadsheet:
Well, so much for the birthday paradox
(edit: oh, now we have actual collisions)
Manuel and I should be in the City around 8:20pm
A bunch of us are meeting at reception in the Wyndham at 8:50 to walk to CMU
{% endraw %}Last updated: Apr 24 2020 at 19:02 UTC


At the moment we are tackling the challenges of the lockdown, and somewhere between online meetings, work, home schooling and cooking we will finish this...


Understand Electricity Generation
Choose your mix of energy sources to always fulfill demand
In the first simulation, you are taking the role of a utility planner. You choose how much of each source of electric power to build. The graph shows a sample week of demand from California’s grid. Did your choice of power plants always fulfill demand? Some energy sources can respond quickly to changing demand (dispatchable) while others do not (non-dispatchable). See if you can find a low-cost, low-carbon allocation that keeps the lights on.
Carbon emissions impact info_outline
Each energy source used for fulfilling energy demand may output CO2.Cost impact
USD/MWh
A megawatt-hour of electricity is about the amount a household uses in a month.
report_problem Energy demand not fulfilled!
Look for empty areas in the energy profile chart to the left; these empty regions show where the unfulfilled demand exists.
Explore Future Assumptions
Now you can explore how assumptions about policies and future costs affect the optimal generation mix. On this page, the utility planning is automatic: the utility planner will always keep the lights on at the least cost. See how your assumptions affect CO2 and costs to consumers across the United States.
Loading scenario outcomes...
Cost and carbon emissions impact info_outline
Your policy choices will affect how much it costs to generate a megawatt-hour of electricity (an amount a typical household uses in a month) and the corresponding CO2 emissions.Energy generation by source info_outline Based upon your policy choices, an optimal mix of energy sources is used to fulfill energy demand for one year, at lowest cost. The table below shows how much each source contributes to the cost and energy consumed.
Compare Policies
Compare the carbon and cost impact of your policy
Your policy can be compared to several different reference policies below. See how your policy outcome stacks up in terms of emissions and budget impact.
About
The goal of the Climate and Energy team in Google Research is to find abundant energy for everyone on the planet. We cannot reach this goal based on today’s fossil fuel technology, because the atmosphere can only absorb a limited amount of CO2 in the near-term. At the current rate CO2 production from combustion, humans will pass the limit for 2℃ average warming in less than 27 years. To reach the goal of abundant energy for everyone, we need to find a source of zero- (or very-low-) carbon electricity that is available 24x7 for all of world’s needs.
Energy is an important part of the world economy: collectively, we spend about $6 trillion dollars a year on it. If we had a zero-carbon 24x7 source of electricity that was much more expensive than fossil fuels are today, then we would not reach the goal of abundant energy for everyone. Such an expensive solution will not give the benefits of plentiful energy to billions of people on the planet.
What is the least expensive way to decarbonize electricity? Many analysts have come up with different answers to this question: 100% renewables plus storage, nuclear power, sequestering carbon from fossil fuels, or a mixture of these.
At Google, we realized that the different answers came from different assumptions that people were making about the future of technology and policies. To help us understand, we created this tool that allows us to quickly see how different assumptions affect the future cost to generate electricity and the amount of carbon dioxide emitted.
Acknowledgements
Concept, design and development by Amber Robson, Corrie Scalisi, Doug Fritz, Drew Bryant, John Platt, Jonny Mack, Josh Freed, Kate Brandt, Matt Jones, Michael Terrell, Orion Pritchard, Philippe Larochelle, Ross Koningstein, Ryan Fitzpatrick and Saleem Van Groenou.
Details
Explore Future Assumptions
On the "Explore Future Assumptions" page, a Linear Program takes on the task of fulfilling demand while minimizing costs, which the user was doing on the preceding "Understand electricity generation"page. The linear program does the calculation over an entire year's worth of electricity data in 13 regions within the Continental United States.
In addition to minimizing costs and fulfilling demand, the linear program also ensures that a specified amount of "Clean Energy" is consumed where Clean Energy is defined as Solar and Wind. Optionally, the user can add Nuclear Power or Carbon Capture and Sequestration (CCS) to the definition of Clean Energy.
If the user selects different cost assumptions for power generation, or a different carbon tax, then the site will show updated results.
CO2 outcomes reported by the tool
The “Understand Electricity Generation” page reports CO2 for California electricity consumption, including imports. Today’s value of 83.1 million metric tons is reported by CalEPA for 2015. The amount of CO2 reported by the tool assumes the latest and most efficient power plants. If we today’s capacity mixture could be reproduced using these latest plants, they would only generate 65.3 million metric tons of CO2. Using efficient natural gas (NG) plants plus hydropower would produce 91.3 million metric tons, which is an increase from today because California uses a large amount of zero-carbon energy.
The CO2 goal in the “Understanding Generation” page comes from the U.S. Deep Decarbonization Pathway Report 15, which projects that in 2050, electricity should generate no more than 0.054 metric tons of CO2 per MWh of electricity (in the most lenient case --- other scenarios may force emissions as low as 0.014).
The “Explore Future Assumptions” page reports CO2 for electricity consumption across the United States. The EIA reports this as 1.82 billion metric tons for 2016. Using the most efficient plants would reduce this to 1.61 billion metric tons. Implementing efficient NG plus hydropower would reduce it further to 1.25 billion metric tons. As in “Understand Generation”, the CO2 goal comes from the U.S. Deep Decarbonization Pathway Report.
Cost outcomes reported by the tool
The costs reported by the tool are an estimate of the cost to generate a megawatt-hour of electricity, about 1.1 times the amount of electricity used by a typical U.S. household.
The cost presented is the Levelized Cost of Electricity (LCOE). LCOE estimates the cost based on three factors: the cost of building the generation plants (per megawatt-hour of capacity), the cost to maintain the plants (per megawatt-hour of capacity per year), and the cost to actually generate the electricity (per megawatt-hour of produced electricity). The LCOE estimate assumes a complete rebuild of the grid, when new plants have replaced old ones.
We assume that the building cost and the fixed maintenance cost are amortized over a 30-year lifespan of the plant. We use a net-present-value calculation for this amortization, with an assumed (real) discount rate of 6%.
We assume that the building cost and the fixed maintenance cost are amortized over a 30-year lifespan of the plant. We use a net-present-value calculation for this amortization, with an assumed (real) discount rate of 6%.
Because the tool is computing LCOE, it will not reflect the price charged to industrial, commercial, or residential customers. Prices for those customers are typically higher than the cost to build and operate the generating plants. The tool doesn’t model how increased costs of generation are passed to customers.
Energy generation cost assumptions
To simplify Policy Simulations, we reduced the choices for energy generation costs to three per technology. For solar, wind, and nuclear power, these are labeled “optimistic future”, “moderate future”, and “today”; to reflect possible future reductions in the capital cost in building these kinds of plants. For natural gas, the choices are “low cost”, “medium cost”, and “high cost”; which reflect future volatility in natural gas fuel prices.
Power Sources
For all power sources, we model costs arising from the following sources:
- Capital: Cost to build the plant ($ per Kilowatt of capacity)
- Fixed: Cost to maintain the plant ($ per Kilowatt of capacity per year)
- Variable: Cost to generate energy ($ per Megawatt hour)
For fossil fuel plants, the variable costs are determined from:
- Fuel: Cost of fuel ($ per MMBTU)
- Heat-rate: Fuel to electricity efficiency (btu per kilowatt hour)
For simulations with a carbon tax, we also source the CO2 generated:
- CO2; Tonnes of CO2 per Megawatt hour
Zero CO2 sources
Costs for solar and wind production have fallen significantly over the past few years and are expected to get even cheaper over time. The price for nuclear power has remained the same over time, but recent startups and developments are working on ‘Advanced Nuclear’ technology which may make nuclear power cheaper in the future.
| Source | Capital ($ / kW) | Fixed ($ / kW-year) |
| Solar Optimistic Future | 6304 | 21.661 |
| Solar Moderate Future | 10404 | 21.661 |
| Solar Today | 22771 | 21.661 |
| Wind Optimistic Future | 13704 | 46.711 |
| Wind Moderate Future | 15004 | 46.711 |
| Wind Today | 16861 | 46.711 |
| Source | Capital ($ / kW) | Fixed ($ / kW-year) | Variable Costs ($ / MWh) |
| Nuclear Optimistic Future | 20003 | 603 | 123 |
| Nuclear Moderate Future | 35003 | 803 | 123 |
| Nuclear Today | 58801 | 99.651 | 101,5 |
We treat hydropower as a legacy resource, assuming that all economic sites for building dams have already been exploited. This caps the total amount of hydropower available to be the existing capacity in each region in the United States.
| Source | Capital ($ / kW) | Fixed ($ / kW-year) | Variable Costs ($ / MWh) |
| Hydropower | 0 (already built) | 14.931 | 2.661 |
Fossil fuel
Fossil fuel technology is mature, with efficiency slowly improving. The biggest factor that affects natural-gas-based electricity is the cost of the natural gas itself. With the widespread use of hydraulic fracturing in the United States, natural gas prices have reached historic lows. For natural gas, we set “low cost” to be the price paid by utilities for natural gas in the second quarter of 2016. However, natural gas prices are volatile in both time and across different countries. To represent this volatility, we set “medium cost” to be a typical European fuel price (January 2016) and “high cost” be $13.5/MMBTU (higher than the highest monthly price in the United States since 2002, but lower than the peak Japanese cost for LNG). We set capital costs to today’s technology to be the same across all three fuel costs.
For natural gas, we consider two types of plant Natural Gas Combined Cycle (NGCC) and Natural Gas Conventional Turbine (NGCT)
For coal, we see very little price changes over time and have fixed coal costs at a single value.
| Source | Capital ($ / kW) | Fixed ($ / kW-year) | Fuel ($ / MMBTU) | Heat rate (BTU / kWh) | CO2 (kg / MMBTU) |
| NGCT $ | 6721 | 6.761 | 2.516 | 85501 | 537 |
| NGCT $$ | 6721 | 6.761 | 2.516 | 85501 | 537 |
| NGCT $$ | 6721 | 6.761 | 2.516 | 85501 | 537 |
| NGCC $ | 10941 | 9.941 | 2.516 | 62001 | 537 |
| NGCC $$ | 10941 | 9.941 | 2.516 | 62001 | 537 |
| NGCC $$ | 10941 | 9.941 | 2.516 | 62001 | 537 |
| Coal | 29342 | 31.182 | 2.142 | 88002 | 987 |
Carbon capture and sequestration (CCS)
Carbon Capture and Sequestration captures CO2 in the exhaust of fossil fuel plants, then transports it to geological storage where it can be sequestered. The additional machinery to capture the CO2 requires energy from the fossil fuel plant, which lowers overall plant efficiency. In addition, carbon capture equipment costs extra capital.
For this simulation, we consider cryogenic capture methods. For different fuel type we add Additional Capital and Fixed Costs to the values in the chart above. We increase the heat rate of the plants, which reflects decrease inefficiency; and multiply Fossil Fuel CO2 output by a CO2 Multiplier to represent the amount of CO2 which escapes the flue at CCS plants.
| Fuel Type | Additional Capital ($ / kW) | Additional Fixed ($ / kW-year) | Additional Variable ($ / kW) | Heat Rate Multiple | CO2 Multiplier |
| NGCT + CCS | 3959,1,2 | 23.27 | 5.091,2 | 1.211 | 0.10 |
| NGCC + CCS | 3959,1,2 | 23.27 | 5.091,2 | 1.151 | 0.10 |
| Coal + CCS | 6569,1,2 | 35.25 | 5.041,2 | 1.181 | 0.10 |
We also assume that CO2 costs $11/tonne to transport and store underground.8
Storage cost assumptions
Storage costs can arise from one of three sources:
- Capital: Net present cost (over 30 years) to build the storage element ($ / Megawatt hour), assuming a 10-year lifespan for Li-Ion batteries.11
- Charge Capital: Cost to build the charging element ($ / Megawatt)
- Discharge Capital: Cost to build the discharging element ($ / Megawatt)
We categorize costs for Storage as:
- Capital: Net present cost to build the storage element ($ / Megawatt hour), assuming a 10-year lifespan
- Charge Capital: Cost to build the charging element ($ / Megawatt)
- Discharge Capital: Cost to build the discharging element ($ / Megawatt)
Storage also has efficiency losses:
- Storage efficiency: amount of energy maintained in untouched system over time: (Storaget+1 - Storaget) / t
- Charge efficiency: amount of energy added to storage per energy taken from the grid.
- Discharge efficiency: amount of energy added to the grid per energy taken from storage.
| Storage Type | Capital ($ / kWh) | Charge Capital ($ / kW) | Discharge Capital ($ / kW) | Charge Efficiency | Discharge Efficiency | Storage Efficiency |
| Li-Ion batteries | 187 | 100 | 100 | 0.9 | 0.9 | 1.0 |
Transmission cost assumptions
We assume long-range transmission is accomplished by High-Voltage DC lines, which cost $334 / MW / km of line, and incur a 3% efficiency loss for every 1000km of line.12
Hydropower limits
When simulating Hydropower, we considered it fully dispatchable with total capacity and generation limits determined by actual 2015 capacity and generation totals.13 Note that 2015 was an El Nino year, although per wikipedia, “During the winter of 2014-15, the typical precipitation and impacts of an El Niño event, did not occur over North America, as the event was weak and on the borderline of being an event.” 14
Sources
- U.S. Energy Information Administration, Cost and Performance Characteristics of New Generating Technologies, Annual Energy Outlook 2017 , (2017).
- U.S. Energy Information Administration. Updated capital cost estimates for utility scale electricity generating plants , (2013).
- IRENA, The power to change: Solar and wind cost reduction potential to 2025 , (2016).
- Clean Air Task Force, Advanced nuclear energy: Need, characteristics, projected costs, and opportunities (2016).
- U.S. Energy Information Administration, Average Power Plant Operating Expenses for Major U.S. Investor-Owned Electric Utilities , (2014).
- U.S. Energy Information Administration, Short-Term Energy Outlook, Table 2. Energy Prices (2017).
- World Bank, Commodity Price Data (The Pink Sheet) , (2017).
- T. Grant, D. Morgan, and K. Gerdes. Carbon dioxide transport and storage costs in NETL studies. Technical Report DOE/NETL-2013/1614, National Energy Technology Laboratory, (2014).
- Mark J. Jensen, Christopher S. Russell, David Bergeson, Christopher D. Hoeger, David J. Frankman, Christopher S. Bence, and Larry L. Baxter. Prediction and validation of external cooling loop cryogenic carbon capture (CCC-ECL) for full-scale coal-fired power plant retrofit. International Journal of Greenhouse Gas Control, 42:200–212, (2015).
- IRENA. REthinking energy 2017: Accelerating the global energy transformation (2017).
- W.G. Manuel. Energy storage study , Turlock Irrigation District, (2014).
- Ryan Pletka, Jagmeet Khangura, Andy Rawlins, Elizabeth Waldren, and Dan Wilson. Capital costs for transmission and substations . Western Electricity Coordinating Council, (2014).
- U.S. Energy Information Administration. Form EIA-860 detailed data , (2016).
- Wikipedia, 2014–16 El Niño event , (2017).
- Williams, J.H., B. Haley, F. Kahrl, J. Moore, A.D. Jones, M.S. Torn, H. McJeon, Pathways to deep decarbonization in the United States . The U.S. report of the Deep Decarbonization Pathways Project of the Sustainable Development Solutions Network and the Institute for Sustainable Development and International Relations. (2014).
Data
Non-dispatchable Profiles
In “Policy Simulation”, in addition to a demand profile, we assumed non-dispatchable profiles for the following sources:
- Coal
- Coal + CCS
- Nuclear
- Solar
- Wind
Coal and Coal + CCS Profiles
We set Coal and Coal + CCS profiles to be “always-on” due to the slow ramp-up and ramp down nature of coal.
Nuclear Profiles
We set Nuclear to be “always-on” except for days 275 - 316 when we set it to half-power. This mimicked profiles we saw from California (CALISO) and Midcontinent Independent Service Operator (MISO) where the nuclear plant was throttled down presumably for repairs and refueling.
Solar Profiles
Solar profiles were generated by assuming profiles matched the https://www.nrel.gov/grid/solar-power-data.html which simulated 6000 sites in the US. Our simulation assumes that for each region, solar would be distributed equally over the sites in that region.
Wind Profiles
Wind profiles were generated by assuming profiles matched the NREL Wind Toolkit data from 2012 which simulated 126,000 sites in the US. Our simulation assumes that for each region, wind would be distributed equally over the sites in that region.
Demand Profiles
Demand profiles were generated from queries to the EIA open data database. (GUI version available here)
Regions
Because EIA groups demand by region all of our simulations were done to match those regions as closely as possible. NREL locations were grouped by states and the states were merged into regions in the following manner:
| Region | States |
| California | CA |
| Carolinas | NC, SC |
| Central | KS, ND, NE, OK, SD |
| ERCOT | TX |
| Florida | FL |
| Midatlantic | DE, MD, NJ, OH, PA, VA, WV |
| Midwest | AR, IA, IL, IN, LA, MI, MN, MO, WI |
| NEISO | CT, MA, ME, NH, RI, VT |
| Northwest | CO, ID, MT, OR, UT, WA, WY |
| NYISO | NY |
| Southeast | AL, GA, MS |
| Southwest | AZ, NM, NV |
| Tennessee Valley Authority | KY, TN |
Code
Code Availability
The policy simulation code is publicly available via GitHub at https://github.com/google/energysimulation
Policy Simulations
The Policy Simulation was performed across the entire United States. We segmented the United States into 13 regions and ran the linear program in each region separately, so that we could run the simulation over an entire year of supply and demand. Each region can get renewable energy from other regions, paying the price for an HVDC line to import the energy. The results of the linear program from every region were summed together to provide the results shown on the web page.
The clean energy fraction slider enforces the same fraction on all regions. That is, a clean energy fraction of X% means that every region generated at least X% of its demand using clean energy (where the definition of clean energy is up to the user).
Sources Local to Region
Local sources in the simulations included:
- Coal
- Coal + CCS
- Hydropower
- NGCC
- NGCT
- NGCC + CCS
- NGCT + CCS
- Nuclear (If “Allow Nuclear” was selected)
- Local Solar
- Local Wind
Today’s Costs and CO2
Today’s Costs are calculated by using existing generation and capacity numbers for 2015. To match them up with simulated costs, we used the same costs, efficiencies and profiles for non-dispatchable sources and demand as we did for our future cost simulations. For example, we assumed that all of the 2015 solar power followed the solar profile of evenly building out all possible solar sites. As another example, we also assumed that efficiency of all natural gas plants matched 2015 technology.
Thus numbers calculated for “Today’s” Costs will be slightly different than actual numbers for 2015. The biggest discrepancy is CO2 emitted because our present-day heat-rate numbers are more efficient than overall numbers for the existing fleet which has been built over the last 30 years.


Details on how to do create one via the Azure portal or with the Azure CLI can be found here.
Navigate to the Azure Data Explorer Web UI via the Azure Portal. The AAD application that you created in step 1 needs to be given viewer access to your Azure Data Explorer database. This is done using the dot command add:
.add database your_db_name viewers ('aadapp=your_client_id;your_tenant_id')
Use the details from the AAD Service Principle from Step 1 to fill in the field below. Then click the Save & Test button.
Detailed instructions on all three steps can found in in the documentation.
The cluster url for your Azure Data Explorer database.
In the Azure Portal, navigate to Azure Active Directory -> Properties -> Directory ID.
**Click here for detailed instructions on setting up an Azure Active Directory (AD) application.**In the Azure Portal, navigate to Azure Active Directory -> App Registrations -> Choose your app -> Application ID.
**Click here for detailed instructions on setting up an Azure Active Directory (AD) application.**To create a new key, log in to Azure Portal, navigate to Azure Active Directory -> App Registrations -> Choose your app -> Keys.
**Click here for detailed instructions on setting up an Azure Active Directory (AD) application.**Choose the default/preferred Database for this Azure Data Explorer Cluster.
x-ms-user-id
header and in the x-ms-client-request-id
header when sending requests to ADX. Can be useful when tracking needs to be done in ADX.


Coats for Kids helps get Saskatoon children ready for winter
by Saskatoon StarPhoenixThe annual Coats for Kids clothing drive distributed warm winter gear to hundreds of Saskatoon school children.
With cooler weather arriving in Saskatoon, an annual clothing drive once again offered school kids free winter gear.
The Rock 102 Coats for Kids Campaign held its final event of the year Wednesday at Bishop Klein Community School, taking donated clothing and letting kids and school representatives select from among hundreds of coats, mitts and other winter items.
The yearly event is done in conjunction with Care & Share Saskatoon as a way to help make sure kids who might not otherwise have the right clothes don’t spend the winter feeling chilly.
“With winter upon us, many children need warm coats, toques and mittens and this is an expense many families cannot afford,” Sandi Meldrum, Executive Director for Care & Share said in a press release issued ahead of the event.


| 520 | (A) | downe sweyande one swelte with-owttyn sware more |
| (C) | ---- no text ---- | |
| (D) | ---- no text ---- | |
| 508 | (E) | þere was non mercy at al . but alle to deth wente |
| (Ex) | ---- no text ---- | |
| 537 | (L) | Doun swowande to swelt without swar more |
| (P) | ---- no text ---- | |
| (U) | ---- no text ---- | |
| (V) | ---- no text ---- |


Keyword: fresh
A freshness qualifier may be applied to a compound judgment premise (such as a function
, relation
, individual
).
By marking a premise as fresh
, any application of the judgment has to supply a fresh name for the premise.
Example:
schema elimE = {
type t
relation p(X:t)
property exists X. p(X)
fresh individual n:t
----------------------
property p(n)
}
type t
relation succ(X:t,Y:t)
axiom exists Y. succ(X,Y)
function next(X:t):t
property succ(X,next(X))
proof {
apply elimE with
n = next(X),
p(Y) = succ(X,Y)
}
In this example, the elimE
schema is defined as requiring a fresh name for the premise n
. When the schema is applied in the proof, n
is bound to next(X)
, which is fresh since no definitions or properties have mentioned it yet.


|
RTMHA Library
2020a
The Master Hearing Aid Algorithms for the OSP System.
|
Beamformer Class. More...
#include <beamformer.hpp>
Public Member Functions | |
| beamformer (size_t delay_len, float *adaptive_filter_taps, size_t adaptive_filter_tap_len, size_t max_frame_size, int adaptation_type, float mu, float delta, float rho, float alpha, float beta, float p, float c, float power_estimate, int bf_on_off, int bf_nc_on_off, int bf_amc_on_off, float nc_thr, float amc_thr, float amc_forgetting_factor) | |
| Beamformer constructor. More... | |
| ~beamformer () | |
| Beamformer destructor. | |
| void | get_e (float *e_l, float *e_r, const float *x_l, const float *x_r, size_t ref_size) |
| Getting e signal (the output signal of this beamformer) More... | |
| int | update_bf_taps (size_t ref_size) |
| Update the taps of the beamformer. More... | |
| void | get_bf_params (int &bf_on_off, int &bf_nc_on_off, int &bf_amc_on_off, float &nc_thr, float &amc_thr, float &amc_forgetting_factor) |
| Getting all parameters from this beamformer. More... | |
| void | set_bf_params (int bf_on_off, int bf_nc_on_off, int bf_amc_on_off, float nc_thr, float amc_thr, float amc_forgetting_factor) |
| Setting all parameters from this beamformer. More... | |
| Public Member Functions inherited from adaptive_filter | |
| adaptive_filter (float *adaptive_filter_taps, size_t adaptive_filter_tap_len, size_t max_frame_size, int adaptation_type, float mu, float delta, float rho, float alpha, float beta, float p, float c, float power_estimate) | |
| Adaptive filter constructor. More... | |
| ~adaptive_filter () | |
| Adaptive filter destructor. | |
| int | update_taps (float *u_ref, float *e_ref, size_t ref_size) |
| To update the taps of this adaptive filter based on the reference signals u_ref and e_ref. More... | |
| size_t | get_max_frame_size () |
| Getting the maximum frame size. More... | |
| void | get_params (float &mu, float &rho, float &delta, float &alpha, float &beta, float &p, float &c, int &adaptation_type) |
| Getting all parameters from this adaptive filter. More... | |
| void | set_params (float mu, float rho, float delta, float alpha, float beta, float p, float c, int adaptation_type) |
| Setting all parameters from this adaptive filter. More... | |
| Public Member Functions inherited from filter | |
| filter (float *taps, size_t tap_size, circular_buffer *cir_buf, size_t max_buf_size) | |
| Filter constructor. More... | |
| ~filter () | |
| Filter destructor. | |
| int | set_taps (const float *taps, size_t buf_size) |
| Setting the filter taps. More... | |
| int | get_taps (float *taps, size_t buf_size) |
| Getting the filter taps. More... | |
| void | cirfir (float *data_in, float *data_out, size_t num_samp) |
| Getting the output of this FIR filter by performing frame-based convolution. More... | |
| size_t | get_size () |
| Getting the number of taps of this FIR filter. More... | |
| void | cirfir (float *data_out, size_t num_samp) |
| Frame-based convolution for FIR filtering. More... | |
Additional Inherited Members | |
| Protected Member Functions inherited from adaptive_filter | |
| int | get_adaptation_type () |
| A function to get the adaptation type. More... | |
| void | get_step_size_weights_IPNLMS (float *taps, float *step_size_weights, float alpha, float beta, float delta, size_t tap_len) |
| A function computing the step size control matrix for IPNLMS-l_0. More... | |
| void | get_step_size_weights_SLMS (float *taps, float *step_size_weights, float p, float c, size_t tap_len) |
| A function computing the step size control matrix for SLMS. More... | |
Beamformer Class.
This beamformer class implements the generalized sidelobe canceller (GSC) using SLMS [Lee et al., IHCON 2018].
Definition at line 39 of file beamformer.hpp.
|
explicit |
Beamformer constructor.
| [in] | delay_len | The length of delay line in samples for beamformer |
| [in] | adaptive_filter_taps | The initial filter taps for adaptive filter in beamformer |
| [in] | adaptive_filter_tap_len | The number of filter taps of adaptive filter in beamformer |
| [in] | max_frame_size | The maximum processing frame size in adaptive filter |
| [in] | adaptation_type | The adaptation type for adaptive filter |
| [in] | mu | A parameter for adaptive filter |
| [in] | delta | A parameter for adaptive filter |
| [in] | rho | A parameter for adaptive filter |
| [in] | alpha | A parameter for adaptive filter |
| [in] | beta | A parameter for adaptive filter |
| [in] | p | A parameter for adaptive filter |
| [in] | c | A parameter for adaptive filter |
| [in] | power_estimate | A parameter for adaptive filter |
| [in] | bf_on_off | A flag for enabling beamformer |
| [in] | bf_nc_on_off | A flag for enabling norm-constrained adaptation |
| [in] | bf_amc_on_off | A flag for enabling adaptation mode controller |
| [in] | nc_thr | A threshold for the norm-constrained adaptation |
| [in] | amc_thr | A threshold for the adaptation mode controller |
Definition at line 32 of file beamformer.cpp.
| void beamformer::get_bf_params | ( | int & | bf_on_off, |
| int & | bf_nc_on_off, | ||
| int & | bf_amc_on_off, | ||
| float & | nc_thr, | ||
| float & | amc_thr, | ||
| float & | amc_forgetting_factor | ||
| ) |
Getting all parameters from this beamformer.
| [out] | bf_on_off | A flag to turn the beamformer on (0: OFF, 1: ON) |
| [out] | bf_nc_on_off | A flag to turn the norm-constrained adaptation on (0: OFF, 1: ON) |
| [out] | bf_amc_on_off | A flag to turn the adaptation mode controller on (0: OFF, 1: ON) |
| [out] | nc_thr | A threshold for the norm-constrained adaptation |
| [out] | amc_thr | A threshold for the adaptation mode controller |
| [out] | amc_forgetting_factor | A forgetting factor to compute the signal power |
Definition at line 142 of file beamformer.cpp.
| void beamformer::get_e | ( | float * | e_l, |
| float * | e_r, | ||
| const float * | x_l, | ||
| const float * | x_r, | ||
| size_t | ref_size | ||
| ) |
Getting e signal (the output signal of this beamformer)
| [out] | e_l | The output signal of this beamformer on the left |
| [out] | e_r | The output signal of this beamformer on the right |
| [in] | x_l | The input signal from the left channel |
| [in] | x_r | the input signal from the right channel |
| [in] | ref_size | The size of each input signal (x_l and x_r have the same size) |
Definition at line 70 of file beamformer.cpp.
| void beamformer::set_bf_params | ( | int | bf_on_off, |
| int | bf_nc_on_off, | ||
| int | bf_amc_on_off, | ||
| float | nc_thr, | ||
| float | amc_thr, | ||
| float | amc_forgetting_factor | ||
| ) |
Setting all parameters from this beamformer.
| [in] | bf_on_off | A flag to turn the beamformer on (0: OFF, 1: ON) |
| [in] | bf_nc_on_off | A flag to turn the norm-constrained adaptation on (0: OFF, 1: ON) |
| [in] | bf_amc_on_off | A flag to turn the adaptation mode controller on (0: OFF, 1: ON) |
| [in] | nc_thr | A threshold for the norm-constrained adaptation |
| [in] | amc_thr | A threshold for the adaptation mode controller |
| [in] | amc_forgetting_factor | A forgetting factor to compute the signal power |
Definition at line 153 of file beamformer.cpp.
| int beamformer::update_bf_taps | ( | size_t | ref_size | ) |
Update the taps of the beamformer.
| [in] | ref_size | The size of each input signal (x_l and x_r have the same size) |
Definition at line 102 of file beamformer.cpp.


∂
We’ve digitized hundreds of catalogs from the famed distributor, Sherry-Lehmann.
From the late 1930s through the 1950s, these beautiful illustrated brochures
list prices from thousands of now rare bottles, helping to chart America’s
appreciation for wine from France, Spain, Italy, and beyond. Help us make it
searchable by transcribing the information that you see on the pages. If you have questions about the project or how to use this site, you can reach us
at<EMAIL_ADDRESS>To learn more about opportunities to support this project or the UC Davis Library’s
world-class wine archives, contact Jean Korinke, Director of Development, at
<EMAIL_ADDRESS>or<PHONE_NUMBER>. For media inquiries, please contact Jessica Nusbaum, at
<EMAIL_ADDRESS>or<PHONE_NUMBER>.
Sherry-Lehmann catalogs
Questions? Comments?
The Team
Powered By


Smacc: a Compiler-Compiler
Advanced Features of SmaCC
This chapter addresses the problem of parsing a language with two interesting features: string interpolations and indentation. SmaCC can handle both, but doing so requires that we use some more advanced techniques. To deal with string interpolations we will use a scanner with multiple states; to deal with indentation will will add some custom token actions to the scanner. Lets look at these techniques one at a time.
Multi-state Scanners
To motivate the need for a multi-state scanner, let's look at a feature of the Grace programming language: string interpolations. Similar features are available in many other languages, including JavaScript and Scala.
In Grace, a StringLiteral
is a sequence of characters enclosed by double quotes;
a StringConstructor
is like a string literal, but can also contain Grace expressions surrounded by braces.
Here is an example.
The value of this string is determined by evaluating the variable count
, converting the answer to a string (by sending it the asString
message),
and interpolating the resulting string in place of the brace expression.
So, if count
is 19
, the final value of the constructed string will be:
If the expressions between braces were restricted to simple identifiers, this would pose no problem for the scanner. However the Grace language allows arbitrary code to appear between the braces. Such code can contain matched string quotes and matched pairs of braces. (In Grace, outside of strings, braces are used to enclose blocks, i.e., they mean roughly the same as brackets in Smalltalk.)
If you remember your formal language theory, you will know that the language of properly nested parentheses is not regular. So we cannot write simple regular expressions in the scanner that will correctly tokenize this language. In essence, the problem is that a regular expression, (or, more precisely, the finite state automaton that recognizes the language defined by that expression) can't maintain an unbounded counter. What should we do?
SmaCC lets us solve this problem by building a scanner with two separate “states”: a special state for scanning strings, and a default state for the rest of the language.
We declare the string
state as follows:
The default state does not need to be declared explicitly.
Scanner rules prefixed with the name of a state operate only in that state. For example:
defines a <stringSegment>
as one or more characters, excluding the double-quote, open-brace, backslash, or any of the control characters between 0
and hex 1F
, or the non-breaking space hex A0
, or one of the backslash escapes n, t, {, }, ", r, l, _ and \.
However, this definition operates only in the string state, which stops it from matching, for example, identifiers.
Similarly, identifiers and whitespace are recognized only in the default
state (which stops them for matching the content of a string).
We want double-quotes (which delimit strings) to be recognized in both states, so we prefix that rule with both names.
What remains is to switch the scanner into the string
state when an opening string quote is encountered.
Then it needs to switch back to the default
state either when it finds either the closing string quote, or an opening brace.
How can we achieve this?
One possibility is to write custom token methods in the scanner, which might count opening and closing braces and determine when the brace that closes the interpolation has been found. But there is a better solution, which takes advantage of the fact that SmaCC does not run the scanner and parser as separate passes. Instead, the parser calls the scanner when, and only when, the parser needs the next token.
Here are the parser rules that change the scanner state:
These rules both match the empty input, so they don't actually parse anything.
Their only function is to force parser actions to be executed.
The non-terminals that they define are used in the rules for StringLiteral
and StringConstructor
.
The first rule says that a StringLiteral
starts with a <dquote>
token, which is followed by an optional <stringSegment>
, and a closing <dquote>
.
The initial StartString
non-terminal can be thought of as a “call” of the StartString
parser action, which, as we saw above, sets the scanner state to string
.
This action won't be executed until after the next token (<dquote>
) is scanned, but when <stringSegment>
is scanned,
the scanner will be in state string
, and thus the scanner rule for <stringSegment>
will be applied.
Similarly, after the end of the <stringSegment>
, the RetDefault
action will return the scanner to the default state.
This won't happen until after the <dquote>
is scanned, but since the rule for <dquote>
is valid in both the default state and the string state, that's OK.
The rule for StringConstructor
is a bit more complicated, and it's for this one that we really need multiple states.
This rule allows multiple interpolations enclosed between braces.
The RetDefault
production is used to return the scanner to the default state before each opening brace.
Then the StartString
production is used to return it to the string state at the closing brace that marks the end of the interpolation.
Once again, because of the way that the parser works, there is a one token “delay” before the state-change takes effect.
This is because the parser won't execute an action until the next token has been read, and the parser has determined that a reduce action is appropriate.
The overall effect is as if there were two different scanners: one for strings, and one for the rest of the source program. The appropriate scanner is used for each part of the input, without further effort.
Indentation-Sensitive Parsing
In many languages, the layout of the source code matters.
Some languages, like Haskell and Python, use layout to indicate the start and end of code blocks.
A common way to describe the syntax of such languages is to imagine a pre-pass over the input that examines the layout and inserts indent and outdent tokens whenever the indentation changes.
The grammar of the language is then written in terms of these tokens.
Grace is somewhat simpler than Haskell and Python in that its code blocks are delimited by {
braces }
.
It is similar, though, in that it requires the body of a code block to be indented more than the surrounding code.
How can we enforce a rule like this using SmaCC?
Using Token Actions to Customize the Scanner
The key idea is to insert custom code into the scanner using SmaCC's token actions. Recall from Section on Token Action Methods that, whenever a SmaCC scanner recognizes a token, a correspondingly-named method in the scanner will be executed—if such a method exists. Now consider the following token definitions from Grace's grammar:
Grace distinguishes between spaces and newlines.
There is an inherited token action for <whitespace>
that resets the scanner to start looking for a new token, but ignores the whitespace itself.
This is fine for our purposes, so long as it applies only to spaces, and not to newlines.
For the latter, we need to write a separate method; the newline
method in GraceScanner
starts like this.
Depending on the state of the scanner, this method will do one of three things.
- Return
self whitespace
if the newline is to be ignored, that is, to be treated like a space. - Return a newline token; the grammar for Grace treats newlines as statement separators, so when the parser sees such a token, it recognizes the end of a statement.
- Signal an exception, which will be caught by the surrounding context and used to produce an error message for the user.
Using Newlines to Separate Statements
To use newlines to separate statements, the grammar for Grace defines the non-terminal Ssep
(statement separator) like this:
Hence, a semicolon, a newline, or any series of semicolons and newlines are all treated as statement separators.
Other productions are then written using Ssep
.
For example, here is part of the definition of a Block
, which is a sequence of statements.
Notice that the grammar is explicit about allowing (but not requiring) a newline (or a semicolon) after the {
that opens the block, allowing (but not requiring) a newline (or a semicolon) before the }
that closes the block, and requiring a newline or semicolon between the Statement
s in the block.
Augmenting the State of the Scanner
What do we mean by “the state of the scanner”? That is very much up to you. You can introduce as many extra instance variables into the scanner as you need to track whatever language features you need to implement.
In Grace, the rule is that indentation must increase after a {
, and must return to the prior level with (or after) the matching }
.
This means, of course, that we need to keep track of the number of {
and }
tokens on the line that has just ended, so that we know if there were more of one than the other.
To do this, we need to add a variable currentLineBraceDepth
to GraceScanner
.
We can do this directly by editing the class definition for GraceScanner
; there is no SmaCC directive to add scanner instance variables
(This is unlike AST instance variables, where we must use the %attributes
directive).
We add an initialize
method in GraceScanner
to set the initial value of currentLineBraceDepth
to 0, and add token action methods leftBrace
and rightBrace
.
Here is the leftBrace
method.
Notice once again that, because it is a token action method, this method must return a token.
Before it does so, it increments the brace depth—but only if the scanner is in the default
state.
If, for example we are in the uninterpString
state, incrementing the brace depth would not be appropriate, because a {
in an uninterpreted string does not start a code block.
In contrast, in an interpreted string, {
does start a code block;
Grace handles that using the SmaCC parser action for starting a string interpolation:
To ensure that indentation corresponds to brace depth, we also need to know the brace depth of the prior line.
At the end of the newline
method, we copy currentLineBraceDepth
into another scanner variable, priorLineBraceDepth
.
For convenience, at the start of the newline
method, we compute the braceChange
as the difference between currentLineBraceDepth
and priorLineBraceDepth
.
Unnamed Tokens
These token actions for braces would work fine if Grace's grammar defined leftBrace
and rightBrace
as named tokens in the scanner, and then used those names in the grammar productions.
This is what it does for newlines, but in fact Grace's grammar is written using literal "{"
and "}"
tokens.
That is, we write:
and not
because the latter is harder to read.
SmaCC happily turns literal tokens like "{"
into scanner tokens; you can see them in the Symbols tab at the bottom of SmaCC's GUI.
But it names these tokens with quoted strings.
This is a problem because we can't write a Smalltalk token action method with a name such as "{"
.
What should we do to set up the connection between the leftBrace
method and the "{"
token?
Before we can answer that question, we need to look and see how SmaCC sets up the connection between a named token and its token action method.
To make this possible, SmaCC generates a method in the scanner called tokenActions
that returns an array.
Each entry in that array corresponds to a scanner token, using the numeric codes that you see in the Scanner tab of SmaCC's GUI.
If the array entry is nil
, there is no special action for the corresponding symbol; otherwise, the scanner performs the action specified.
The code that implements this is found at the end of SmaCCScanner>>reportLastMatch
.
Here is a slightly simplified version:
In this code, matchActions
is an array of scanner symbols that describe the token that has just been matched.
Recall that SmaCC allows you to write overlapping symbol definitions; if you do so, this array will contain all those that match the input.
If there is a single match, the array will have size 1.
The array contains the numeric symbol codes used internally by the scanner; these codes are used to index into the tokenActions
array.
Let's assume that SmaCC happens to assign the numeric code 41 to <whiteSpace>
, 42 to <comment>
and 43 to <newline>
.
The tokenActions
array generated by SmaCC will contain mostly nil
, but elements 41, 42 and 43 will then be #whitespace
, #comment
and #newline
, because SmaCC found methods with these names in the scanner when it generated the table.
Now that we know about the tokenActions
array, it's a fairly simple matter to patch-in the names of the leftBrace
and rightBrace
token action methods at the appropriate indexes.
We do this in the class side initialization, so that it is done just once, not every time a scanner is run.
Here are the methods.
Inconveniently, the list of symbol names is stored in an instance method of the parser, not in the scanner.
We add a class instance variable symbolNames
to cache this information in the scanner.
You will notice that, in addition to patching-in actions for the left and right braces, we also patch-in actions for the assignment symbol and for reserved words.
We will not discuss these actions here, because they are not related to handling layout.
Having calculated the new token actions array, we need to get SmaCC to use it. If SmaCC had stored it in a variable, all that would be necessary would be to overwrite that variable. But it is stored as a literal in a method! We handle this problem by simply generating and compiling a modified version of that method. The ease with which Smalltalk lets us do meta-programming saves the day.
There is actually an alternative to compiling a new method, which we will encourage you not to use!
Because of what many people regard as a bug in the Smalltalk language specification, it is actually possible to modify an array literal.
That is, rather than copying the literal as we have done, it is possible to perform at:put:
operations on the literal itself!
There are several problems with doing this, not the least of which is that when you read the code, you will see one thing, but when you execute it, you will get another.
In our view, recompiling the method that returns the literal is a far better approach.
Perhaps in a future version of SmaCC, there will be a directive to connect un-named tokens with token actions. Then, the work-around we have just described will not be necessary. Nevertheless, it does well-illustrate the amazing flexibility of SmaCC.
Closing Blocks
With brace depth being tracked by the leftBrace
and rightBrace
methods, the newline
method has the information that it needs to check that the indentation increases after each left brace.
We also need to check that indentation returns to the previous level with the matching right brace.
This requires that we keep a stack of prior indentations, push the new indentation onto the stack then we see an increase, pop it when we see a decrease, and check that the new, decreased indentation is the same as the value on the top of the stack.
This requires another scanner instance variable, which we call indentStack
.
There is a slight complication because Grace allows both of the following forms
and
that is, a right brace can appear either at the end of the last line of a block, in which case the line containing the brace is indented, or at the start of the line that follows the block. In the latter case the right brace is not indented, but must be at the same indentation as the line that contains the corresponding left brace. The second case looks better, but is actually anomalous: when the line containing just the right brace starts, the block has not yet been closed, so we would normally expect the line to be indented. It's fairly easy to make an exception for this case:
The scanner variable currentCharacter
is set by SmaCC to contain the character following those that make up the token that has just been matched—in our case, the character following the newline and the leading spaces.
So it is easy to check if it is a right brace, and adjust braceChange
if necessary.
The scanner variable outputStream
is a stream that contains all of the characters that SmaCC has determined make up the current token.
In the case of a newline token, this will be the line end sequence itself, and the spaces that follow it.
We use this variable to calculate the current indent:
The Grace language specification says that a line feed following a carriage return is ignored, so we are careful not to include it when we calculate the indentation.
It should also be possible to use the character position reported by SmaCCLineNumberStream
to calculate the current indent.
Continuation Lines
If Grace changed indentation only to indicate an increase in the brace level, the newline
token action method would be quite simple, and we would already have the all the pieces we need.
However, Grace also uses indentation to indicate a continuation line, that is, two or more physical lines that should be treated as a single logical line.
This is useful when a single statement is too long to fit on a line, and it is necessary to break it into several lines; the additional line breaks should not be treated as spaces.
Python signals continuation lines by requiring that the programmer escape the intermediate newline by preceeding it with a backslash; this is simpler for the scanner, but uglier for the reader.
Grace's rule is that an increase in indentation that does not correspond to the start of a code block signals a continuation line. Further lines with the same (or greater) indentation are part of the continuation; the end of the continuation is signalled by a return to the previous indentation, or by an un-matched left brace.
Dealing with continuations requires another state variable indentOfLineBeingContinued
, which is nil
if no line is being continued.
Another variable, maxIndentOfContinuation
, tracks the maximum indentation of the continuation.
Ignoring Blank Lines
Another of Grace's indentation rules says that blank lines are ignored for indentation purposes.
If this were not so, the number of spaces on a line that appears blank would be significant—a problem since these trailing spaces are invisible, and are often removed by text editors.
Lines that contain nothing but a comment are treated as blank for the same reason; it seems excessive to require that the //
symbol that introduces the comment to be at a specific indentation.
Implementing the first part of this rule is simple, but the part that treats comment lines as blank requires look-ahead.
Here is how we implement the isLineEmpty
check.
The first line returns early with true
if there is nothing on the line but spaces; remember that any leading spaces will have been included as part of the <newline>
token.
The second line returns early with false
if the first non-space character is not /
, because in those cases we know that the line does not start with a comment.
The remaining case is where the first non-space character is /
; we need to see if it is followed by a second /
, indicating a comment, or by some other character, in which case the initial /
was an operator symbol.
To do this we use explore:
on stream
, the scanner instance variable that names the inout stream.
explore: withABlock
saves the position of the stream, evaluate the code withABlock
, and then resets the stream to the saved position.
The method explore:
is implemented in the wrapper class SmaCCLineNumberStream
, but it is only as good as the position:
method in the underlying stream.
Currently, there are some issues with position:
on streams that contain multiple-byte characters; the workaround is to read the whole stream into a string, and then create a stream on the string.
The Rest of the Story
If you wish to see all the details, the code for the Grace parser is available on github.


Twitter badge
using progressive enhancement and lazy loading
unstyle badge with no user data
grey badge with user data
orange badge with user data
blue badge with user data
black badge with user data
My twitter updates


Philippians 1:25
And having this confidence, I know that I shall abide and continue with you all for your furtherance and joy of faith;


06 Apr 2012
Over the past week or so, we had a need to enroll macs automagically with a Lion Profile Manager server. My first plan was to do what Charles Edge did in his recent blog post and use DeployStudio. Then I remembered another post by Charles on /usr/bin/profiles and wondered if I could make a workflow that can be used throughout our deployment and system maintenance process - yup, the humble pkg, that can be popped into Munki for existing macs, installed with DeployStudio for imaging and pushed out with ARD if need be.
Get the code from GitHub
Assuming you’ve got The Luggage set up, first off you’ll need your enrollment and trust profiles:
1. Create a new enrollment profile
2. Give your enrollement profile a name
3. Download the trust profile
4. Download the enrollment profile
If your attachments auto open, click cancel when you’re asked if you want to install the profiles so they stay in ~/Downloads. Rename them to enroll.mobileconfig and trust.mobileconfig and pop them into the directory you cloned from GitHub. A quick make pkg
and you’ve got your package.
03 Apr 2012
Inspired by some of the cool kids, I’ve spent the last couple of evenings migrating my blog over to Octopress. The main motivators were my desire to put my posts under version control (we’ve been going a bit nuts for Git at Pebble towers recently), and that I wanted to use the excellent Byword app to compose my posts (I just need to work out how I’m going to be able to use the iOS app to publish on the go - probably some Dropbox trickery).
Plus, using Ruby scripts and Rsync to publish the blog really appealed to my (not so) inner geek.
Anyway, normal mac-type sysadmin-y posts will resume shortly.
24 Mar 2012
Before I descend into a massive rant, let me preface this post with this: I hate BT. I always have, and I probably always will. They are generally the most incompetent, uncooperative company on the planet.
Let me take you back to October 2011. I was perusing the BT website looking for BT Infinity - their brand name for up to 40meg VDSL. I popped in my postcode and was told that I was in a trial area for FTTP at a stonking 100meg. Obviously I thought about the pain I was letting myself in for, having to deal with BT, but I was sure that I could cope with it if I was getting such insanely fast Internet at the end of it.
If only I knew how painful it was going to be.
Read more →
23 Feb 2012
I’ve pushed some updates to this script, mainly switching to using The Luggage for making the package. As ever, it’s up on Github.
01 Feb 2012
So you’ve lovingly crafted your never booted image in InstaDMG. It’s fully up to date and lovely. And then you try to enable FileVault 2. As you have no Recovery HD, it’s not going to happen.
I’ve tried several methods to get around this, including taking an image of an existing Recovery HD. It worked (ish), but didn’t feel right. Then I found this post on google +. I’ve lovingly ripped off the method and put it into a package for deployment with DeployStudio, ARD, or anything else that can take normal packages. You can download everything from my GitHub, usage instructions are in the readme.


Description: Develop a discussion area for users to discuss a topic
Category: Web Development
Timeframe: 4 months
Progress
About me section
Course Completed: Javascript, PHP, Ruby on Rails


Ernakulam is a sprawling metropolis that beautifully combines its natural wonders with providing a base for a majority of the State’s business enterprises. Flanked by the Arabian sea, it is easily among the most visited locations in Kerala. It is an extremely important commercial centre but also has a plethora of destinations for tourists to enjoy. The city of Kochi, with its fine natural harbour, is the undisputed crown jewel of the district. From historic locations that transport you to a time when it acted as the commercial hub of the legendary Spice Route to exotic trips on boats where one can simply relax and soak in the weather, Kochi never disappoints. Ernakulam has always epitomized the Malayali spirit of welcoming all who visit it and this tradition continues to this day.
A popular hangout among Kochiites, Marine drive is the perfect place for an evening stroll. A walkway by the backwaters it is lined by beautiful Gulmohar trees and benches on either side. There are two bridges on each end of the walkway; one, in the shape of a rainbow and the other, shaped as a boat. Conducted boat tours take tourists to places of interest. One can also opt for small canoes. Restaurants, cafes, and vendors selling peanuts and bhajjis make it a perfect haunt for the young crowd. Bay Pride Mall, a posh shopping complex nearby, with a barista and restaurant is an added attraction.
Known as the Ernakulathappan Temple, the God of this temple is named after the city (Ernakulam). The deity Shiva, faces the west towards the sea which is a rarity. The idols of Lord Shiva and Parvathi found in the temple are believed to be self created. The Arattu procession where the deity is taken for a ritual bath in the temple pond marks the end of the eight day festival during the months of January and February.
The palace on a hill-top was built in 1865 and was the residence of the Raja of Cochin. The largest archeological museum of Kerala it is set up in 52 acres of land and has 49 buildings. Exhibits displayed in its 18 galleries include the royal throne and other antique furniture, precious jewellery used by the kings and queens, royal chariots, palanquins, royal clothes, earthen, brass and bronze vessels, gold coins, and swords and spears. There is a special section for jewellery exhibits where the huge royal gold crown studded with precious stones is put on display. The palace grounds have a deer park, children’s park, heritage museum, archeological museum and a Mulla Panthal (jasmine grove) where the royal family used to take a stroll. The palace is open to the public on all days except Mondays.
10 kms from the city this museum at Edappally was the brainchild of industrialist and philanthropist, R Madhavan Nair. The sculptures in the museum depict the history of Kerala through the Neolithic Age to the Modern age. The one hour light and sound show depicts Kerala’s journey through the past to the present day. There is a gallery of contemporary and miniature paintings holding over 200 pieces of art.
The palace situated in an area of 15 acres was built by the Dutch in 1744. The palace is now a heritage hotel with lush green lawns surrounding it. It also has a golf course. Boats to this island start from the High Court Jetty. Country boats (Machuvas) can also be hired near the Jetty.
It is India’s first European church built in 1503 by a group of Portuguese. The Portuguese explorer Vasco Da Gama was buried here in 1524. 14 years later his remains were taken back to Lisbon, however, his tombstone remains intact. Regular services are conducted on all days of the week in English and Malayalam at the church.
Named after the viceroy of India, Lord Willingdon, this 775 acre island was created from the soil dredged up while deepening Kochi’s Harbour in 1928. This engineering feat was led by Sir Robert Bristow. The island lies between mainland Ernakulam and Mattancherry. the island houses the Cochin Port Trust and the headquarters of the Southern Naval Command. Luxury hotels such as the Taj Malabar, the Trident Hilton and Casino Hotel are also built on the island.
The Jew Street in Fort Cochin is a quaint little street with curio shops that have an array of antiques in wood, brass and bronze. The shops have antiquities from all over the country. The street turned a shopping hub after the Jews living here returned to Israel. Their dwellings fell into disrepair and these structures were torn down to build new ones. Whatever was retrieved- woodwork, furniture, artefacts, vessels and brass work, fund their way into shops that sprang up in the alleys.
The first eco-friendly tourist village in India, Kumbalngi has numerous home stay options. It is a tiny village facing the backwaters in the western part of Cochin. Kalagramam, the artists’ village is a major attraction.


http://www.susangranger.com/
Susan Granger's review of "PROOF OF LIFE" (Warner Bros.)
Abduction of multinational executives has become big business according to William Prochnau in a 1998 VANITY FAIR piece, "Adventures In the Ransom Trade," the provocative article that inspired this timely adventure story. So, after an exciting, if bewildering, opening sequence in which a hostage negotiator (Russell Crowe) extracts a victim from war-torn Chechnya, the action switches to Tecala, high in the Andes of Latin America, where an American engineer (David Morse) is kidnapped and held for ransom. Abandoned by his employer and insurance company, his "little hippie" wife (Meg Ryan) and annoyingly strident sister (Pamela Reed) try to deal with the guerrillas - until Russell Crowe, an expert in "K&R" (kidnap & ransom) comes to their rescue, along with a fellow mercenary, David Caruso.
Directed by Taylor Hackford from a script by Tony Gilroy, this is a relevant, multi-layered, suspense-filled drama. Filmed in London, Poland and Ecuador, it's no-expense-spared filmmaking, even as it wallows in melodramatic moments. And, like "Casablanca," you're left wondering right to the end if the leading lady will wind up in the arms of her husband or his would-be savior. Flush from his success in "Gladiator," Crowe offers further proof that he's a virile, self-assured, charismatic leading man, while Meg Ryan embodies the psychological torture inflicted on the wife. Their off-screen romantic trysts which became tabloid fodder should fuel the box-office. David Morse subtly shows the strain of captivity, but the Latinos, unfortunately, are stock stereotypes, particularly the cocaine-crazed bandidos. On the Granger Movie Gauge of 1 to 10, "Proof of Life" is a high-tension 7. If you're looking for a thriller, this one delivers the goods.
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


Release Procedure
When it is time for a release please do the following (in
order).
Requirements:
- java 1.6 sdk
- ant
- svn checkout of trunk
- svn checkout of maven (recommended)
Prepare Documents
- Update wiki ReleaseNotes,
mainPage
- Build and commit javadocs
- Ensure you have correct svn mime type setup, the default
is wrong.
Do not commit javadocs without changing your subversion
properties.
Build it
- Tag it (/tags/2.0)
- ant javadoc dist (specify version when asked)
Upload it
- Upload to googlecode (title: Objectify-Appengine v2.0 ,
tags: OsSys-All,Featured)
- Deprecate old versions
- Commit maven checkout
Announce it
- Push an email out to user list, appengine-java list
- Announce on TSS/Other


The NullVolatilityModel
sets the volatility of the security to zero. It's the default volatility model for the underlying asset of Future Options.
underlyingSecurity.VolatilityModel = VolatilityModel.Null;
underlying_security.VolatilityModel = VolatilityModel.Null
To view the implementation of this model, see the LEAN GitHub repository.


Welcome
Saeed Iqbal Khattak
| |
Change Password
|
saeed.iqbal Logout
|
NEW JOB
DELETE JOB
VIEW JOB
Select Country:
City:
Insert New Job
Send Values
Delete Job
Job Title: Web Developer
Key Words : HTML/CSS, PHPm ASP.NET, Javascript, Ruby on Rails, Python Django and Search Engine Optimisation
Job Location: Punjab, Pakistan
Responsibilities
ORG:
NETSOL
Write well designed, testable, efficient code by using best software development practices
Create site layout/user interface by using standard HTML/CSS practices
Integrate data from various back-end services and databases
Top-notch programming skills and in-depth knowledge of modern HTML/CSS
Familiarity with at least one of the following programming languages: PHP, ASP.NET, Javascript or Ruby on Rails
Basic knowledge of Search Engine Optimisation process
Salary:
75K


{{define "Head"}} {{ template "bootstrap-table" . }} {{ template "clipboard" . }} {{end}} {{define "body"}}
Pricing guide to sell assets in system with 30% Jita price markup.
White: 30% markup
Yellow: Below 30% markup due to regional competition
Red: Selling at a loss due to regional competition
| Type | Quantity | Jita Buy Price | Jita Sell Price | Region Orders | Station Orders | Region Price | Station Price | Marked Up Price |
|---|