Any SVN client will have some way of setting proxy server settings. For example, the Subversive plugin simply use
whatever proxy settings have been specified for Eclipse (Preferences ? General ? Network Connections).
For the command-line client, you can add proxy settings in the servers configuration file:
Every directory in the workspace has a .svn directory which contains various types of metadata.
THE OVERALL SCENARIO TO GUIDE THIS DOCUMENT
create repo with the standard setup: tags / branches / trunk
create users Jack and Jill
Jack:
list
checkout (or, export)
create a file in trunk
svn status
svn add
svn status
svn log
svn commit (mention what a good commit message looks like)
svn status
svn log
Jill:
svn checkout
modify the file
svn commit
Jack:
modify file
svn status -s (get a preview of upcoming merge conflicts!)
svn update
resolve merge conflicts
svn commit
-- tag
svn move
svn copy
svn delete
-- branch
svn copy
svn revert
> cd /
> svnadmin create repo
> ll repo
-rw-r--r-- 1 jack users 229 Dec 28 23:21 README.txt
drwxr-xr-x 5 jack users 170 Dec 28 23:21 conf/
drwxr-sr-x 15 jack users 510 Dec 28 23:21 db/
-r--r--r-- 1 jack users 2 Dec 28 23:21 format
drwxr-xr-x 11 jack users 374 Dec 28 23:21 hooks/
drwxr-xr-x 4 jack users 136 Dec 28 23:21 locks/
> vi repo/conf/authz
[/]
jack = rw
jill = rw
* = r
> vi repo/conf/passwd
[users]
jack = pwd
jill = pwd
> vi repo/conf/svnserve.conf
[general]
anon-access = read
auth-access = write
password-db = passwd
authz-db = authz
realm = My Repository
> svnserve -d
> mkdir project
> cd project/
> mkdir trunk
> mkdir tags
> mkdir branches
> cd ..
> svn import --username jack --password pwd project svn://localhost/svn/project -m "Initial setup"
Adding project/trunk
Adding project/branches
Adding project/tags
Committed revision 1.
> svn ls svn://localhost/svn/project
branches/
tags/
trunk/
> svn co svn://localhost/svn/project/trunk project
Checked out revision 1.
> cd project/.svn
> ll
total 0
drwxr-xr-x 7 a106358 users 238 Dec 29 13:06 .svn/
> ll .svn
total 8
-r--r--r-- 1 jack users 155 Dec 29 13:06 entries
drwxr-xr-x 2 jack users 68 Dec 29 13:06 prop-base/
drwxr-xr-x 2 jack users 68 Dec 29 13:06 props/
drwxr-xr-x 2 jack users 68 Dec 29 13:06 text-base/
drwxr-xr-x 5 jack users 170 Dec 29 13:06 tmp/
> mkdir -p com/bitbakery/project
> echo "; This is our first source file" >> com/bitbakery/project/foo.arc
> svn st
? com
> svn add com
A com
A com/bitbakery
A com/bitbakery/project
A com/bitbakery/project/foo.arc
> svn commit -m "Added first source code file to the project"
Adding com
Adding com/bitbakery
Adding com/bitbakery/project
Adding com/bitbakery/project/foo.arc
Transmitting file data .
Committed revision 2.
> svn st
> vi com/bitbakery/project/foo.arc
; This is our first source file
(def hello (name) (str "Hello, " name))
> svn revert -R .
Reverted 'com/bitbakery/project/foo.arc'
> svn st
> less com/bitbakery/project/foo.arc
; This is our first source file
com/bitbakery/project/foo.arc (END)
A few notes about svn revert:
> cd /Users/jill/dev
> svn co svn://localhost/svn/project/trunk project
A project/com
A project/com/bitbakery
A project/com/bitbakery/project
A project/com/bitbakery/project/foo.arc
Checked out revision 2.
> cd project/
> svn log
------------------------------------------------------------------------
r2 | jack | 2011-12-29 13:14:13 -0600 (Thu, 29 Dec 2011) | 1 line
Added first source code file to the project
------------------------------------------------------------------------
r1 | jack | 2011-12-29 11:37:16 -0600 (Thu, 29 Dec 2011) | 1 line
Initial setup
------------------------------------------------------------------------
> vi com/bitbakery/project/foo.arc
; This is our first source file
(mac hi (name) `(str "Hello, " ,name))
> svn commit -m "Added a 'Hello, world' macro"
Sending com/bitbakery/project/foo.arc
Transmitting file data .
Committed revision 3.
FROM JACK:
> svn up
Conflict discovered in 'com/bitbakery/project/foo.arc'.
Select: (p) postpone, (df) diff-full, (e) edit,
(mc) mine-conflict, (tc) theirs-conflict,
(s) show all options: s
(e) edit - change merged file in an editor
(df) diff-full - show all changes made to merged file
(r) resolved - accept merged version of file
(dc) display-conflict - show all conflicts (ignoring merged version)
(mc) mine-conflict - accept my version for all conflicts (same)
(tc) theirs-conflict - accept their version for all conflicts (same)
(mf) mine-full - accept my version of entire file (even non-conflicts)
(tf) theirs-full - accept their version of entire file (same)
(p) postpone - mark the conflict to be resolved later
(l) launch - launch external tool to resolve conflict
(s) show all - show this list
Select: (p) postpone, (df) diff-full, (e) edit, (r) resolved,
(mc) mine-conflict, (tc) theirs-conflict,
(s) show all options: e
This will open a text editor
; This is our first source file
<<<<<<< .mine
(def hello (name) (str "Hello, " name))
=======
(mac hi (name) `(str "Hello, " ,name))
>>>>>>> .r3
...modify the file to reflect the changes we wish to save in this file:
; This is our first source file
(def hello (name) (str "Hello, " name))
Upon saving the file, you're once again asked what to do with it. Assuming we resolved our merge conflicts,
we would now want to mark the file as resolved:
Select: (p) postpone, (df) diff-full, (e) edit, (r) resolved,
(mc) mine-conflict, (tc) theirs-conflict,
(s) show all options: r
G com/bitbakery/project/foo.arc
Updated to revision 3.
> svn commit -m "Replaced 'hi' macro with function 'hello'"
Sending com/bitbakery/project/foo.arc
Transmitting file data .
Committed revision 4.
Note that we could have chosen 'p' to postpone the merge, and then edited the conflicted file(s) later. If we do this,
then we would need to run svn resolve to mark the conflicted files as resolved before we can commit our changes.
FROM JILL:
> svn up .
U com/bitbakery/project/foo.arc
Updated to revision 4.
FROM JACK:
Tag the build:
> svn cp svn://localhost/svn/project/trunk svn://localhost/svn/project/tags/4 -m "Tagging the
latest successful build (r4)"
Committed revision 5.
> svn log -v -r5 svn://localhost/svn/project
------------------------------------------------------------------------
r5 | jack | 2011-12-29 14:13:02 -0600 (Thu, 29 Dec 2011) | 1 line
Changed paths:
A /project/tags/4 (from /project/trunk:4)
Tagging the latest successful build (r4)
------------------------------------------------------------------------
> svn ls svn://localhost/svn/project/tags
4/
Jack wants to be able to do some work in isolation without having to worry about whether or not he's making problems
for Jill, so he decides to work in his own branch for a while. During this time, he'll periodically update his branch
with any changes that Jill makes to trunk, but he won't merge his changes back to trunk until he's finished.
Until then, Jack can commit changes to his branch, and they won't be visible to Jill, who's working in trunk.
> svn cp svn://localhost/svn/project/trunk svn://localhost/svn/project/branches/jacks-branch -m
"Branching from trunk at r4 to develop a particular feature"
Committed revision 6.
> svn log -q svn://localhost/svn/project/tags/4
------------------------------------------------------------------------
r5 | jack | 2011-12-29 14:13:02 -0600 (Thu, 29 Dec 2011)
------------------------------------------------------------------------
r4 | jack | 2011-12-29 14:03:48 -0600 (Thu, 29 Dec 2011)
------------------------------------------------------------------------
r3 | jack | 2011-12-29 13:48:37 -0600 (Thu, 29 Dec 2011)
------------------------------------------------------------------------
r2 | jack | 2011-12-29 13:14:13 -0600 (Thu, 29 Dec 2011)
------------------------------------------------------------------------
r1 | jack | 2011-12-29 11:37:16 -0600 (Thu, 29 Dec 2011)
------------------------------------------------------------------------
> svn log -q svn://localhost/svn/project/trunk
------------------------------------------------------------------------
r4 | jack | 2011-12-29 14:03:48 -0600 (Thu, 29 Dec 2011)
------------------------------------------------------------------------
r3 | jack | 2011-12-29 13:48:37 -0600 (Thu, 29 Dec 2011)
------------------------------------------------------------------------
r2 | jack | 2011-12-29 13:14:13 -0600 (Thu, 29 Dec 2011)
------------------------------------------------------------------------
r1 | jack | 2011-12-29 11:37:16 -0600 (Thu, 29 Dec 2011)
------------------------------------------------------------------------
> svn log -q svn://localhost/svn/project/branches/jacks-branch
------------------------------------------------------------------------
r6 | jack | 2011-12-29 14:21:26 -0600 (Thu, 29 Dec 2011)
------------------------------------------------------------------------
r4 | jack | 2011-12-29 14:03:48 -0600 (Thu, 29 Dec 2011)
------------------------------------------------------------------------
r3 | jack | 2011-12-29 13:48:37 -0600 (Thu, 29 Dec 2011)
------------------------------------------------------------------------
r2 | jack | 2011-12-29 13:14:13 -0600 (Thu, 29 Dec 2011)
------------------------------------------------------------------------
r1 | jack | 2011-12-29 11:37:16 -0600 (Thu, 29 Dec 2011)
------------------------------------------------------------------------
A couple of things to note here:
- Subversion does not explicitly support the notions of tagging and branching; Subversion merely creates
lightweight copies. Thus, the only difference between copying and tagging and branching is by convention
- Every change to the repository (copy, commit, merge, import...) creates a unique revision number with a
Subversion repository. However, any given branch will only see certain revisions.
Jack is travelling in time and space... Note that conceptually, svn switch is no different than deleting your local
workspace,
and checking out from a different location in the repository.
> svn switch -r 2 svn://localhost/svn/project/trunk
U com/bitbakery/project/foo.arc
Updated to revision 2.
> svn switch -r HEAD svn://localhost/svn/project/trunk
U com/bitbakery/project/foo.arc
Updated to revision 6.
> svn switch svn://localhost/svn/project/branches/jacks-branch
At revision 6.
> svn info
Path: .
URL: svn://localhost/svn/project/branches/jacks-branch
Repository Root: svn://localhost/svn
Repository UUID: 6ef053a4-0651-4e6b-8e37-4247f30db5d5
Revision: 6
Node Kind: directory
Schedule: normal
Last Changed Author: jack
Last Changed Rev: 6
Last Changed Date: 2011-12-29 14:21:26 -0600 (Thu, 29 Dec 2011)
> vi com/bitbakery/project/foo.arc
; This is our first source file
(def hello (name) (str "Hello, " name))
(def goodbye (name) (str "Goodbye, " name))
> svn commit -m "Added goodbye function"
Sending com/bitbakery/project/foo.arc
Transmitting file data .
Committed revision 7.
FROM JILL:
...but this remains invisible to Jill, who is still working on trunk:
> svn up
At revision 7.
> svn info
Path: .
URL: svn://localhost/svn/project/trunk
Repository Root: svn://localhost/svn
Repository UUID: 6ef053a4-0651-4e6b-8e37-4247f30db5d5
Revision: 7
Node Kind: directory
Schedule: normal
Last Changed Author: jack
Last Changed Rev: 4
Last Changed Date: 2011-12-29 14:03:48 -0600 (Thu, 29 Dec 2011)
> svn log -q
------------------------------------------------------------------------
r4 | jack | 2011-12-29 14:03:48 -0600 (Thu, 29 Dec 2011)
------------------------------------------------------------------------
r3 | jack | 2011-12-29 13:48:37 -0600 (Thu, 29 Dec 2011)
------------------------------------------------------------------------
r2 | jack | 2011-12-29 13:14:13 -0600 (Thu, 29 Dec 2011)
------------------------------------------------------------------------
r1 | jack | 2011-12-29 11:37:16 -0600 (Thu, 29 Dec 2011)
------------------------------------------------------------------------
> echo "; This is our second source file" >> com/bitbakery/project/bar.arc
> svn add com/bitbakery/project/bar.arc
A com/bitbakery/project/bar.arc
> svn commit -m "Added second source file"
Adding com/bitbakery/project/bar.arc
Transmitting file data .
Committed revision 8.
BACK IN THE LAND OF JACK:
> svn merge svn://localhost/svn/project/trunk
--- Merging r6 through r8 into '.':
A com/bitbakery/project/bar.arc
> svn st
M .
A + com/bitbakery/project/bar.arc
> svn commit -m "Merged in latest changes from trunk"
Sending .
Adding com/bitbakery/project/bar.arc
Committed revision 9.
> svn up
At revision 9.
> svn log
------------------------------------------------------------------------
r9 | jack | 2011-12-29 17:05:19 -0600 (Thu, 29 Dec 2011) | 1 line
Merged in latest changes from trunk
------------------------------------------------------------------------
r7 | jack | 2011-12-29 16:44:49 -0600 (Thu, 29 Dec 2011) | 1 line
Added goodbye function
------------------------------------------------------------------------
r6 | jack | 2011-12-29 14:21:26 -0600 (Thu, 29 Dec 2011) | 1 line
Branching from trunk at r4 to develop a particular feature
------------------------------------------------------------------------
r4 | jack | 2011-12-29 14:03:48 -0600 (Thu, 29 Dec 2011) | 1 line
Replaced 'hi' macro with function 'hello'
------------------------------------------------------------------------
r3 | jack | 2011-12-29 13:48:37 -0600 (Thu, 29 Dec 2011) | 1 line
Added a 'Hello, world' macro
------------------------------------------------------------------------
r2 | jack | 2011-12-29 13:14:13 -0600 (Thu, 29 Dec 2011) | 1 line
Added first source code file to the project
------------------------------------------------------------------------
r1 | jack | 2011-12-29 11:37:16 -0600 (Thu, 29 Dec 2011) | 1 line
Initial setup
------------------------------------------------------------------------
> svn pg svn:mergeinfo
/project/trunk:6-8
BACK IN THE LAND OF JILL:
> echo "; This is our third source file" >> com/bitbakery/project/baz.arc
> svn add com/bitbakery/project/baz.arc
A com/bitbakery/project/baz.arc
> svn commit -m "Added yet another source file"
Adding com/bitbakery/project/baz.arc
Transmitting file data .
Committed revision 10.
...AND BACK IN THE LAND OF JACK:
> svn merge svn://localhost/svn/project/trunk
--- Merging r9 through r10 into '.':
A com/bitbakery/project/baz.arc
> svn commit -m "Merged in latest changes from trunk"
Sending .
Adding com/bitbakery/project/baz.arc
Committed revision 11.
> svn pg svn:mergeinfo
/project/trunk:6-10
Or to give a little more detail, let's look at the history of our branch, included that stuff which we merged in from
trunk:
> svn log -q -g
------------------------------------------------------------------------
r11 | jack | 2011-12-29 17:11:52 -0600 (Thu, 29 Dec 2011)
------------------------------------------------------------------------
r10 | jack | 2011-12-29 17:10:55 -0600 (Thu, 29 Dec 2011)
Merged via: r11
------------------------------------------------------------------------
r9 | jack | 2011-12-29 17:05:19 -0600 (Thu, 29 Dec 2011)
------------------------------------------------------------------------
r8 | jack | 2011-12-29 17:01:36 -0600 (Thu, 29 Dec 2011)
Merged via: r9
------------------------------------------------------------------------
r7 | jack | 2011-12-29 16:44:49 -0600 (Thu, 29 Dec 2011)
------------------------------------------------------------------------
r6 | jack | 2011-12-29 14:21:26 -0600 (Thu, 29 Dec 2011)
------------------------------------------------------------------------
r4 | jack | 2011-12-29 14:03:48 -0600 (Thu, 29 Dec 2011)
------------------------------------------------------------------------
r3 | jack | 2011-12-29 13:48:37 -0600 (Thu, 29 Dec 2011)
------------------------------------------------------------------------
r2 | jack | 2011-12-29 13:14:13 -0600 (Thu, 29 Dec 2011)
------------------------------------------------------------------------
r1 | jack | 2011-12-29 11:37:16 -0600 (Thu, 29 Dec 2011)
------------------------------------------------------------------------
This shows explicitly what Jack has done on his branch, along with those changes from trunk which Jack has merged into
jacks-branch.
AND BACK WE GO TO THE LAND OF JILL:
> svn pg svn:mergeinfo
> svn merge svn://localhost/svn/project/branches/jacks-branch
--- Merging r6 through r11 into '.':
C com/bitbakery/project/baz.arc
U com/bitbakery/project/foo.arc
C com/bitbakery/project/bar.arc
Summary of conflicts:
Tree conflicts: 2
Whah?!? What the?? A closer look reveals the issue: we're trying to merge stuff from trunk back on to itself. Let's back
out our changes and try again:
> svn pg svn:mergeinfo
/project/branches/jacks-branch:6-11
> svn revert -R .
Reverted '.'
Reverted 'com/bitbakery/project/baz.arc'
Reverted 'com/bitbakery/project/foo.arc'
Reverted 'com/bitbakery/project/bar.arc'
> svn pg svn:mergeinfo
OK, all is well again. What we need is some way to tell Subversion to "reintegrate" jacks-branch into trunk - in other
words, merging in changes from jacks-branch whil ignoring anything which jacks-branch had pulled in from trunk:
> svn merge --reintegrate svn://localhost/svn/project/branches/jacks-branch
--- Merging differences between repository URLs into '.':
U com/bitbakery/project/foo.arc
> svn pg svn:mergeinfo
/project/branches/jacks-branch:6-11
> svn commit -m "Reintegrated jacks-branch into trunk"
Sending .
Sending com/bitbakery/project/foo.arc
Transmitting file data .
Committed revision 12.
Committed revision 12.
> svn log -q -g
------------------------------------------------------------------------
r12 | jack | 2011-12-29 17:43:29 -0600 (Thu, 29 Dec 2011)
------------------------------------------------------------------------
r11 | jack | 2011-12-29 17:11:52 -0600 (Thu, 29 Dec 2011)
Merged via: r12
------------------------------------------------------------------------
r10 | jack | 2011-12-29 17:10:55 -0600 (Thu, 29 Dec 2011)
Merged via: r12, r11
------------------------------------------------------------------------
r9 | jack | 2011-12-29 17:05:19 -0600 (Thu, 29 Dec 2011)
Merged via: r12
------------------------------------------------------------------------
r8 | jack | 2011-12-29 17:01:36 -0600 (Thu, 29 Dec 2011)
Merged via: r12, r9
------------------------------------------------------------------------
r7 | jack | 2011-12-29 16:44:49 -0600 (Thu, 29 Dec 2011)
Merged via: r12
------------------------------------------------------------------------
r6 | jack | 2011-12-29 14:21:26 -0600 (Thu, 29 Dec 2011)
Merged via: r12
------------------------------------------------------------------------
r10 | jack | 2011-12-29 17:10:55 -0600 (Thu, 29 Dec 2011)
------------------------------------------------------------------------
r8 | jack | 2011-12-29 17:01:36 -0600 (Thu, 29 Dec 2011)
------------------------------------------------------------------------
r4 | jack | 2011-12-29 14:03:48 -0600 (Thu, 29 Dec 2011)
------------------------------------------------------------------------
r3 | jack | 2011-12-29 13:48:37 -0600 (Thu, 29 Dec 2011)
------------------------------------------------------------------------
r2 | jack | 2011-12-29 13:14:13 -0600 (Thu, 29 Dec 2011)
------------------------------------------------------------------------
r1 | jack | 2011-12-29 11:37:16 -0600 (Thu, 29 Dec 2011)
------------------------------------------------------------------------
BACK IN JACK'S WORLD
Jack is still working on his branch, and we'd like to another merge from trunk. But now we have the same problem as
before! How do we merge changes from
> svn merge --record-only -c 12 svn://localhost/svn/project/trunk
> svn pg svn:mergeinfo
/project/trunk:6-12
By performing a "record-only" merge from trunk to jacks-branch, we're essentially updating the svn:mergeinfo property so
that we don't attempt to merge our own changes back into ourselves...
XXX WHY IS THIS NECESSARY?? I DIDN'T SEE ISSUES WHEN I TRIED A REGULAR MERGE!!


---
layout: example.html
title: Filter Map Example
shortdesc: SDK app showing how to filter data
docs: >
Adding an tiled map
Adding an geojson map
Filter Data, displaying only features that match
Filters are combined until reset
Example (STATE_NAME, equal, Kentucky) then (STATE_NAME, equal, Missouri)
Example (P_MALE, greater than, .5)
---


Villa Vught / Mecanoo
- Curated by Paula Pintos
- about 13 hours
Houses · Vught, The Netherlands
- version="1.0" encoding="UTF-8"? Architects: Mecanoo
- AreaArea of this architecture projectArea: 683.0 m2
- version="1.0" encoding="UTF-8"?YearCompletion year of this architecture project Year: 2019
- version="1.0" encoding="UTF-8"?PhotographsPhotographs: Ossip Architectuurfotografie
- version="1.0" encoding="UTF-8"?ManufacturersBrands with products used in this architecture project Manufacturers: Bealmortex, Derix, Duravit, Elshof, Hotbath, Schüco
Text description provided by the architects. The Villa in the Dutch countryside near Vught gives a contemporary twist to the local farmstead typology. Traditionally, the Dutch ‘hoeve’ is an ensemble of farmhouses and living quarters loosely clustered around a courtyard. The central open space is protected, yet open to the surrounding landscape. This spatial arrangement guided the design of the Villa. The Villa’s functions are distributed within three distinct volumes, shaped to resemble the vernacular of a small village. The two lower volumes are shaped like typical gabled barns directly connected to the surrounding gardens. The higher volume captures the view of the wide landscape and forms a striking contrast with the lower buildings.
The tallest element, the most prominent building, contains the master bedroom on the ground floor, children’s rooms on the upper floors and a roof terrace at the top. Of the two barns, one is furnished as a living room, kitchen with dining area and a large veranda on the south-west side, with a workspace and playroom on the first floor. The other barn features a cooking studio where up to twenty people can participate in culinary classes, workshops and team-building activities led by the client. Next to the studio is a garage, storage area and a guest suite on the first floor. Large sliding doors in the centre can be opened to reveal an entrance gate to the courtyard.
The design ambition endeavoured to connect the residential functions while maintaining the detached traditional farmstead typology. To this end, a half-sunken corridor, concealed beneath a grass mound, links the taller landmark volume with the barn’s living room. The barn containing the cooking studio and guesthouse is completely detached, maintaining sightlines from the courtyard to the surrounding landscape.
The Villa’s construction and detailing also emulate the Dutch ‘hoeve’ or farmstead. The exterior dark bronze anodised aluminium cladding, chosen to seamlessly extend beyond the façade to the rooftop, is profiled to resemble the corrugated iron roofs of nearby farm buildings. The window frames, which traditionally have a brighter colour, have a lighter bronze aluminium finish. Throughout each building, views towards the landscape are carefully framed. Rather than making wide full-height openings, windows are placed like picture frames, adorning the walls with selected images of the surrounding farmlands.
Wood is used for both the structure and interior finish, a material that is at once sustainable and visually warm. The three buildings have a cross-laminated timber structure and European silver fir interior surfaces, a type of wood that has an exceptionally smooth and uniform texture. Compared to other solid construction methods, relatively little energy is needed for the production and processing of cross-laminated timber. It contributes to sustainable CO2 storage as well. The villa has an Energy Performance Coefficient (EPC) of 0.26 and is heated and cooled with electric heat pumps.


Kahuku wind farm company completes transport of turbine parts ahead of schedule | Honolulu Star-Advertiser
UPDATE: 5:25 p.m.
Kamalani Keliikuli of Ku Kiai Kahuku, a group that opposes the planned Na Pua Makani wind farm, said the group plans to continue their battle against the project in the wake of the completed transport of all the large turbine parts to Kahuku.
“Even though the transport is over, we are still fighting it,” Keliikuli said.
AES U.S. Generation said earlier today that the overnight transport convoys are done, earlier than expected. (See below.)
Keliikuli said they plan to continue reaching out to the government and speaking with lawmakers to discuss their concerns.
3:05 p.m.
The transport of all of the large turbine parts for the planned Na Pua Makani wind farm project in Kahuku is completed, a company official said today.
“We have completed transport for Na Pua Makani ahead of schedule and will continue to work towards helping Hawaii achieve its 100% renewable energy future,” Mark Miller, chief operating officer of the AES U.S. Generation businesses, said in an emailed statement to the Honolulu Star-Advertiser this afternoon. “The project will be operational, producing wind energy for the island of Oahu, on schedule in the summer of 2020.
“We are deeply grateful to HPD and DOT for their professionalism and dedication in ensuring the roads were safe for everyone during our transport process. No further road closures for the project are scheduled at this time,” Miller said.
The transport of turbine equipment for eight wind turbines from Kahuku to Kalaeloa began in mid-October. AES initially estimated the transport of turbine parts to continue until Nov. 26.
Police have made nearly 200 arrests, including 21 overnight, of protesters trying to block the turbine-part convoy from traveling from Kalaeloa to Kahuku five nights a week starting on Oct. 17.
Miller said, “Last week, our community engagement team renewed attempts to have meaningful dialogue with interested community members about the Na Pua Makani wind project. AES is committed to continuing those conversations to understand how we can further our commitment to being a good neighbor and give back to the community.”
Previous coverage:
Honolulu police arrested more people overnight in the ongoing protest against the Na Pua Makani wind farm project in Kahuku.
Police said officers arrested 21 people — 19 people in Kalaeloa and two people in Kahuku — for disobeying a police officer.
Those arrested in Kalaeloa were subsequently released after posting bail that ranged from $100 to $1,000, police said.
Two people arrested in Kahuku were also released after each posted $500 bail.
Since mid-October, AES Corp. has been transporting turbine parts during the late night to early morning hours from Kalaeloa to Kahuku five days a week.
The company is constructing eight turbines in Kahuku which is slated to start operating next year.
Opponents claim the turbines lead to health problems and are built too close to schools, farms and homes.
AES maintain the turbines will have no ill health effects.


| Created: | 9/18/2012 12:00:18 PM |
| Modified: | 9/18/2012 12:01:16 PM |
| Project: | |
| Advanced: |
| Operation | ||||
|
Public Debug( message: String, |
||||
|
Details:
Sequential
|
||||
|
Public Debug( exception: Exception, |
||||
|
Details:
Sequential
|
||||
|
Public Error( exception: Exception, |
||||
|
Details:
Sequential
|
||||
|
Public Info( Info: String, |
||||
|
Details:
Sequential
|
||||
|
Public Info( exception: Exception, |
||||
|
Details:
Sequential
|
||||
|
Public Init():void |
||||
|
Details:
Sequential
|
||||
|
Public Warn( message: String, |
||||
|
Details:
Sequential
|
||||
|
Public Warn( exception: Exception, |
||||
|
Details:
Sequential
|
| Element | Source Role | Target Role |
|
WcfLoggerService Class |
Name: |
Name: |
|
Details:
|
| Object | Type | Connection | Notes |
| WcfLoggerService | Class | Realization |


|
Standard Reference Data Program |
Data Gateway |
Chemistry WebBook |
|
Go To: Top, Constants of diatomic molecules, References, Notes / Error Report
Data compilation copyright by the U.S. Secretary of Commerce on behalf of the U.S.A. All rights reserved.
Data compiled as indicated in comments:
LL - S.G. Lias and J.F. Liebman
LLK - S.G. Lias, R.D. Levin, and S.A. Kafafi
RDSH - H.M. Rosenstock, K. Draxl, B.W. Steiner, and J.T. Herron
View reactions leading to BCl+ (ion structure unspecified)
| IE (eV) | Method | Reference | Comment |
|---|---|---|---|
| 10.2 | DER | Lias, Bartmess, et al., 1988 | LL |
| 12. ± 1. | EI | Srivastava and Farber, 1971 | LLK |
| Ion | AE (eV) | Other Products | Method | Reference | Comment |
|---|---|---|---|---|---|
| B+ | 13.6 ± 0.2 | Cl | EI | Marriott and Craggs, 1957 | RDSH |
Go To: Top, Gas phase ion energetics data, References, Notes / Error Report
Data compilation copyright by the U.S. Secretary of Commerce on behalf of the U.S.A. All rights reserved.
Data compiled by: K.P. Huber and G. Herzberg
| State | Te | ωe | ωexe | ωeye | Be | αe | γe | De | βe | re | Trans. | ν00 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| A 1Π | 36750.92 | 849.04 HQ | 11.37 1 | -0.100 | 0.7054 2 | 0.00820 3 | -0.00050 | 1.60E-06 4 | 0.00000027 | 1.6894 | A ↔ X 5 VR | 36754.30 HQ |
| missing citation | ||||||||||||
| a 3Π1 | 20200 | 911 | 5.7 | 0.6986 | 0.0047 | 1.698 | a → X V | 20235.70 Z | ||||
| Lebreton, Marsigny, et al., 1971 | ||||||||||||
| X 1Σ+ | 0 | 839.12 HQ | 5.11 | 0.6838 2 | 0.00646 | 0.00000172 | 0.00000007 | 1.7159 |
| 1 | ωeze = -0.0271. |
| 2 | RKR potential curve Gelebart and Johannin-Gilles, 1968. |
| 3 | missing note |
| 4 | Extrapolation of A 1Π; see Barrow, 1960. |
| 5 | Radiative lifetime τ(v=0,1,2)= 19.1 ns Hesser, 1968; f00(A←X) = 0.11. |
| 6 | βe= 0.7E-7 |
Go To: Top, Gas phase ion energetics data, Constants of diatomic molecules, Notes / Error Report
Data compilation copyright by the U.S. Secretary of Commerce on behalf of the U.S.A. All rights reserved.
Lias, Bartmess, et al., 1988
Lias, S.G.; Bartmess, J.E.; Liebman, J.F.; Holmes, J.L.; Levin, R.D.; Mallard, W.G.,
Gas-phase ion and neutral thermochemistry,
J. Phys. Chem. Ref. Data, Suppl. 1, 1988, 17, 1-861. [all data]
Srivastava and Farber, 1971
Srivastava, R.D.; Farber, M.,
Thermodynamic properties of the B-Cl-F system from mass spectrometer investigations,
J. Chem. Soc. Faraday Trans., 1971, 67, 2298. [all data]
Marriott and Craggs, 1957
Marriott, J.; Craggs, J.D.,
Ionization and dissociation by electron impact. II. Boron trifluoride and boron trichloride,
J. Electron. Control, 1957, 3, 194. [all data]
Lebreton, Marsigny, et al., 1971
Lebreton, J.; Marsigny, L.; Ferran, J.,
Caracterisation d'une nouvelle transition de la molecule 11B35Cl (systeme 3Π1→X1Σ+),
C.R. Acad. Sci. Paris, Ser. C, 1971, 272, 1094. [all data]
Gelebart and Johannin-Gilles, 1968
Gelebart, F.; Johannin-Gilles, A.,
Les courbes d'energie potentielle des etats 1Π et 1Σ+ de la molecule BCl,
C.R. Acad. Sci. Paris, Ser. B, 1968, 267, 408. [all data]
Barrow, 1960
Barrow, R.F.,
Dissociation energies of the gaseous monohalides of boron, aluminium, gallium, indium, and thallium,
Trans. Faraday Soc., 1960, 56, 952. [all data]
Hesser, 1968
Hesser, J.E.,
J. Chem. Phys., 1968, 48, 2518. [all data]
Go To: Top, Gas phase ion energetics data, Constants of diatomic molecules, References
| AE | Appearance energy |
Copyright for NIST Standard Reference Data is governed by the Standard Reference Data Act.
|
Standard Reference Data Program |
Data Gateway |
Chemistry WebBook |
If you have comments or questions about this site, please contact us.


Having technical difficulties? We've got you covered
From PCs, Macs, Smartphones, home networks, digital assistants, and more, The Digital Helpers provides unbiased, expert advice and support. Start checking things off your tech to-do list and start getting the most out of your technology.


Path to R Bin:
The path to R bin (location to binary executable) is the folder where the R binary is located. StoX will use this path to trigger R commands. When pressing OK, a check will be performed to ensure the dependent Rstox packages are installed.


OUR GOAL:
Do you ever feel motivated to exercise and go on YouTube to find workouts. . . only to find yourself giving up after the first 30 seconds because there are too many videos or they are too easy/hard? Finesse is here to help you find a workout that is the best for you without having to sort through thousands of videos. Everyone is different and wants something different. Our website will help you save time and provide you quality professional workouts. (Note: most of our workouts are geared towards women)
MAJOR FEATURES
* Navigation Bar
* Multi-Survey Form
* Over two hundred videos with professional trainers
* Video Randomizer
* View more tabs
* Social media share buttons
LANGUAGES USED
HTML, CSS, JavaScript, Bootstrap
CONTACT US HERE


Object.finalize()
method.
According to the Object.finalize()
documentation:
The finalization mechanism is inherently problematic. Finalization can lead to performance issues, deadlocks, and hangs. Errors in finalizers can lead to resource leaks; there is no way to cancel finalization if it is no longer necessary; and no ordering is specified among calls to
finalize
methods of different objects. Furthermore, there are no guarantees regarding the timing of finalization. Thefinalize
method might be called on a finalizable object only after an indefinite delay, if at all.
Configure the inspection:
finalize()
implementations with an empty method body or a body
containing only if
statements that have a condition which evaluates
to false
and is a compile-time constant. For performance reasons it
can be beneficial to override a non-trivial finalize()
with an empty
implementation in a subclass. An empty final finalize()
implementation
can also be used to prevent subclasses from overriding.


Control your cell using the mouse, w for eject, space for split. Add <skinname> in your username for skins.
If you cannot connect to the servers, check if you have some anti virus or firewall blocking the connection.


Use bind mounts
Estimated reading time: 15 minutesBind mounts have been around since the early days of Docker. Bind mounts have limited functionality compared to volumes. When you use a bind mount, a file or directory on the host machine is mounted into a container. The file or directory is referenced by its full or relative path on the host machine. By contrast, when you use a volume, a new directory is created within Docker’s storage directory on the host machine, and Docker manages that directory’s contents.
The file or directory does not need to exist on the Docker host already. It is created on demand if it does not yet exist. Bind mounts are very performant, but they rely on the host machine’s filesystem having a specific directory structure available. If you are developing new Docker applications, consider using named volumes instead. You can’t use Docker CLI commands to directly manage bind mounts.
Choose the -v or --mount flag
Originally, the -v
or --volume
flag was used for standalone containers and
the --mount
flag was used for swarm services. However, starting with Docker
17.06, you can also use --mount
with standalone containers. In general,
--mount
is more explicit and verbose. The biggest difference is that the -v
syntax combines all the options together in one field, while the --mount
syntax separates them. Here is a comparison of the syntax for each flag.
Tip: New users should use the
--mount
syntax. Experienced users may be more familiar with the-v
or--volume
syntax, but are encouraged to use--mount
, because research has shown it to be easier to use.
-v
or--volume
: Consists of three fields, separated by colon characters (:
). The fields must be in the correct order, and the meaning of each field is not immediately obvious.- In the case of bind mounts, the first field is the path to the file or directory on the host machine.
- The second field is the path where the file or directory is mounted in the container.
- The third field is optional, and is a comma-separated list of options, such
as
ro
,consistent
,delegated
,cached
,z
, andZ
. These options are discussed below.
--mount
: Consists of multiple key-value pairs, separated by commas and each consisting of a<key>=<value>
tuple. The--mount
syntax is more verbose than-v
or--volume
, but the order of the keys is not significant, and the value of the flag is easier to understand.- The
type
of the mount, which can bebind
,volume
, ortmpfs
. This topic discusses bind mounts, so the type is alwaysbind
. - The
source
of the mount. For bind mounts, this is the path to the file or directory on the Docker daemon host. May be specified assource
orsrc
. - The
destination
takes as its value the path where the file or directory is mounted in the container. May be specified asdestination
,dst
, ortarget
. - The
readonly
option, if present, causes the bind mount to be mounted into the container as read-only. - The
bind-propagation
option, if present, changes the bind propagation. May be one ofrprivate
,private
,rshared
,shared
,rslave
,slave
. - The
consistency
option, if present, may be one ofconsistent
,delegated
, orcached
. This setting only applies to Docker Desktop for Mac, and is ignored on all other platforms. - The
--mount
flag does not supportz
orZ
options for modifying selinux labels.
- The
The examples below show both the --mount
and -v
syntax where possible, and
--mount
is presented first.
Differences between -v
and --mount
behavior
Because the -v
and --volume
flags have been a part of Docker for a long
time, their behavior cannot be changed. This means that there is one behavior
that is different between -v
and --mount
.
If you use -v
or --volume
to bind-mount a file or directory that does not
yet exist on the Docker host, -v
creates the endpoint for you. It is
always created as a directory.
If you use --mount
to bind-mount a file or directory that does not
yet exist on the Docker host, Docker does not automatically create it for
you, but generates an error.
Start a container with a bind mount
Consider a case where you have a directory source
and that when you build the
source code, the artifacts are saved into another directory, source/target/
.
You want the artifacts to be available to the container at /app/
, and you
want the container to get access to a new build each time you build the source
on your development host. Use the following command to bind-mount the target/
directory into your container at /app/
. Run the command from within the
source
directory. The $(pwd)
sub-command expands to the current working
directory on Linux or macOS hosts.
The --mount
and -v
examples below produce the same result. You
can’t run them both unless you remove the devtest
container after running the
first one.
$ docker run -d \
-it \
--name devtest \
--mount type=bind,source="$(pwd)"/target,target=/app \
nginx:latest
$ docker run -d \
-it \
--name devtest \
-v "$(pwd)"/target:/app \
nginx:latest
Use docker inspect devtest
to verify that the bind mount was created
correctly. Look for the Mounts
section:
"Mounts": [
{
"Type": "bind",
"Source": "/tmp/source/target",
"Destination": "/app",
"Mode": "",
"RW": true,
"Propagation": "rprivate"
}
],
This shows that the mount is a bind
mount, it shows the correct source and
destination, it shows that the mount is read-write, and that the propagation is
set to rprivate
.
Stop the container:
$ docker container stop devtest
$ docker container rm devtest
Mount into a non-empty directory on the container
If you bind-mount into a non-empty directory on the container, the directory’s existing contents are obscured by the bind mount. This can be beneficial, such as when you want to test a new version of your application without building a new image. However, it can also be surprising and this behavior differs from that of docker volumes.
This example is contrived to be extreme, but replaces the contents of the
container’s /usr/
directory with the /tmp/
directory on the host machine. In
most cases, this would result in a non-functioning container.
The --mount
and -v
examples have the same end result.
$ docker run -d \
-it \
--name broken-container \
--mount type=bind,source=/tmp,target=/usr \
nginx:latest
docker: Error response from daemon: oci runtime error: container_linux.go:262:
starting container process caused "exec: \"nginx\": executable file not found in $PATH".
$ docker run -d \
-it \
--name broken-container \
-v /tmp:/usr \
nginx:latest
docker: Error response from daemon: oci runtime error: container_linux.go:262:
starting container process caused "exec: \"nginx\": executable file not found in $PATH".
The container is created but does not start. Remove it:
$ docker container rm broken-container
Use a read-only bind mount
For some development applications, the container needs to write into the bind mount, so changes are propagated back to the Docker host. At other times, the container only needs read access.
This example modifies the one above but mounts the directory as a read-only
bind mount, by adding ro
to the (empty by default) list of options, after the
mount point within the container. Where multiple options are present, separate
them by commas.
The --mount
and -v
examples have the same result.
$ docker run -d \
-it \
--name devtest \
--mount type=bind,source="$(pwd)"/target,target=/app,readonly \
nginx:latest
$ docker run -d \
-it \
--name devtest \
-v "$(pwd)"/target:/app:ro \
nginx:latest
Use docker inspect devtest
to verify that the bind mount was created
correctly. Look for the Mounts
section:
"Mounts": [
{
"Type": "bind",
"Source": "/tmp/source/target",
"Destination": "/app",
"Mode": "ro",
"RW": false,
"Propagation": "rprivate"
}
],
Stop the container:
$ docker container stop devtest
$ docker container rm devtest
Configure bind propagation
Bind propagation defaults to rprivate
for both bind mounts and volumes. It is
only configurable for bind mounts, and only on Linux host machines. Bind
propagation is an advanced topic and many users never need to configure it.
Bind propagation refers to whether or not mounts created within a given
bind-mount or named volume can be propagated to replicas of that mount. Consider
a mount point /mnt
, which is also mounted on /tmp
. The propagation settings
control whether a mount on /tmp/a
would also be available on /mnt/a
. Each
propagation setting has a recursive counterpoint. In the case of recursion,
consider that /tmp/a
is also mounted as /foo
. The propagation settings
control whether /mnt/a
and/or /tmp/a
would exist.
| Propagation setting | Description |
|---|---|
shared |
Sub-mounts of the original mount are exposed to replica mounts, and sub-mounts of replica mounts are also propagated to the original mount. |
slave |
similar to a shared mount, but only in one direction. If the original mount exposes a sub-mount, the replica mount can see it. However, if the replica mount exposes a sub-mount, the original mount cannot see it. |
private |
The mount is private. Sub-mounts within it are not exposed to replica mounts, and sub-mounts of replica mounts are not exposed to the original mount. |
rshared |
The same as shared, but the propagation also extends to and from mount points nested within any of the original or replica mount points. |
rslave |
The same as slave, but the propagation also extends to and from mount points nested within any of the original or replica mount points. |
rprivate |
The default. The same as private, meaning that no mount points anywhere within the original or replica mount points propagate in either direction. |
Before you can set bind propagation on a mount point, the host filesystem needs to already support bind propagation.
For more information about bind propagation, see the Linux kernel documentation for shared subtree.
The following example mounts the target/
directory into the container twice,
and the second mount sets both the ro
option and the rslave
bind propagation
option.

Configure the selinux label
If you use selinux
you can add the z
or Z
options to modify the selinux
label of the host file or directory being mounted into the container. This
affects the file or directory on the host machine itself and can have
consequences outside of the scope of Docker.
- The
z
option indicates that the bind mount content is shared among multiple containers. - The
Z
option indicates that the bind mount content is private and unshared.
Use extreme caution with these options. Bind-mounting a system directory
such as /home
or /usr
with the Z
option renders your host machine
inoperable and you may need to relabel the host machine files by hand.
Important: When using bind mounts with services, selinux labels (
:Z
and:z
), as well as:ro
are ignored. See moby/moby #32579 for details.
This example sets the z
option to specify that multiple containers can share
the bind mount’s contents:
It is not possible to modify the selinux label using the --mount
flag.
$ docker run -d \
-it \
--name devtest \
-v "$(pwd)"/target:/app:z \
nginx:latest
Configure mount consistency for macOS
Docker Desktop for Mac uses osxfs
to propagate directories and files shared from macOS
to the Linux VM. This propagation makes these directories and files available to
Docker containers running on Docker Desktop for Mac.
By default, these shares are fully-consistent, meaning that every time a write happens on the macOS host or through a mount in a container, the changes are flushed to disk so that all participants in the share have a fully-consistent view. Full consistency can severely impact performance in some cases. Docker 17.05 and higher introduce options to tune the consistency setting on a per-mount, per-container basis. The following options are available:
-
consistent
ordefault
: The default setting with full consistency, as described above. -
delegated
: The container runtime’s view of the mount is authoritative. There may be delays before updates made in a container are visible on the host. -
cached
: The macOS host’s view of the mount is authoritative. There may be delays before updates made on the host are visible within a container.
These options are completely ignored on all host operating systems except macOS.

- Learn about tmpfs mounts.
- Learn about storage drivers.


The End of Week Seven: Learned Some JavaScript
February 15, 2016
So, first off...
It might just be me but I feel like the documentation for JavaScript is far easier to read
This is just a link to working with objects but boy, if it helped me through two challenges and really stuck with me, I'm gonna recommend it.
It got me through two challenges in like half an hour, 45 minutes which was a great feeling (anybody who did that in less, don't tell me. Let me keep my sense of self-accomplishment).
I mean... I guess Ruby has objects...
Yeah, I'm pretty sure they do BUT!!! I'm looking at the Ruby docs and my eyes are just glazing over from the overwhelming information like...no...*fades into the distance*...
But going straight to the mozilla docs of JavaScript and its just beautiful.
var dog = {name: "Diggy", age: 4, faveToy: "Mr. Lamby"}
OR YOU COULD EVEN DO IT LIKE THIS:
var dog = new Object();
dog.name = "Diggy";
It's just so easy for me to finally comprehend!!!


| Package | Description |
|---|---|
| com.peterverzijl.softwaresystems.qwirkle |
| Modifier and Type | Method and Description |
|---|---|
Node |
Board.createEmptyNode(Direction aDirection,
Node aBlock)
Creates an empty node in a certain direction used to expand the board.
|
Node |
Board.findDuplicateNode(Vector2 aPosition,
Direction aDirection)
Searches the frontier list of empty nodes for a node with the same position.
|
Node |
Node.getNeighborNode(Direction d)
Returns a node by cardinal direction.
|
Node |
Node.getNeighborNode(int i)
Returns a neighbor node by index.
|
Node[] |
Node.getNeighborNodes()
Returns an array of four neighbor nodes.
|
static Node |
Board.moveStringToNode(java.lang.String message)
Reads a move string and converts this to a node.
|
| Modifier and Type | Method and Description |
|---|---|
java.util.Map<java.lang.Integer,java.util.List<Node>> |
ComputerPlayer.determineBestMove(java.util.List<Block> aPossibleMoves,
java.util.List<Node> aPossiblePositions,
java.util.List<Node> aSet)
Determines the best move based on all possible moves,
the possible positions and the set.
|
java.util.List<Node> |
HumanTUIPlayer.determineMove()
Provides the user of the program with an input loop to play the game.
|
java.util.List<Node> |
ComputerPlayer.determineMove()
Determines a move based on the board and the hand of the player.
|
java.util.List<Node> |
Game.getCopyBoard()
Gets the placed nodes of the unit.
|
java.util.List<Node> |
Board.getEmptySpaces()
Makes a copy of the empty spaces and returns the copy list.
|
java.util.List<Node> |
Game.getFrontier()
Returns the board frontier, aka all possible empty spaces where the player can
place his/her blocks.
|
java.util.List<Node> |
Board.getPlacedBlocks()
Getter for all blocks placed on the board.
|
java.util.List<Node> |
Board.giveHint(java.util.List<Node> possibleMoves,
java.util.List<Node> currentSet,
Block aBlock)
Fills in a block to find out which positions offer a valid move.
|
java.util.Map<Player,java.util.List<Node>> |
Game.startingPlayer(java.util.Map<Player,java.util.List<Node>> aMapWithFirstMoves)
Receives the first move of all the players and determine which player
should start by calculation the scores of each move.
|
| Modifier and Type | Method and Description |
|---|---|
void |
Board.addFrontiers(Node aNode)
Checks if the node already has a neighbor node exists.
|
int |
Board.calcScore(Node aBlock)
Calculates the score of the last stone placed.
|
Node |
Board.createEmptyNode(Direction aDirection,
Node aBlock)
Creates an empty node in a certain direction used to expand the board.
|
boolean |
Node.equals(Node other) |
boolean |
Board.isValidColor(Node lastMove,
Direction aDirection)
Looks if the color requirement is fulfilled by checking all the neighbor node,
in all possible Directions.
|
boolean |
Board.isValidShape(Node aMove,
Direction aDirection)
Looks if the shape requirement is fulfilled by checking all the neighbor node,
in all possible Directions.
|
void |
Board.removeFrontier(Node aBlock)
Searches for the node in the list with possible moves and removes it.
|
void |
Board.setFrontier(Node aPlacedNode)
Adds a node to the empty node list.
|
void |
Node.setNeighborNode(Node n,
Direction d)
Sets the node of a given cardinal direction.
|
void |
Node.setNeighborNode(Node n,
int i)
Sets the node of a given location index.
|
boolean |
Board.setPlacedBlock(Node node)
Sets a block if the position of the node that has to be added
is also the position of a node in the empty node list
Else the move is invalid.
|
boolean |
Board.setStone(Node node)
Updates the empty nodes list if the setPlacedBlock(node) == true.
|
| Modifier and Type | Method and Description |
|---|---|
boolean |
Game.checkHand(java.util.List<Node> set)
Checks if all the given blocks are in the hand of the player.
|
java.util.Map<java.lang.Integer,java.util.List<Node>> |
ComputerPlayer.determineBestMove(java.util.List<Block> aPossibleMoves,
java.util.List<Node> aPossiblePositions,
java.util.List<Node> aSet)
Determines the best move based on all possible moves,
the possible positions and the set.
|
java.util.Map<java.lang.Integer,java.util.List<Node>> |
ComputerPlayer.determineBestMove(java.util.List<Block> aPossibleMoves,
java.util.List<Node> aPossiblePositions,
java.util.List<Node> aSet)
Determines the best move based on all possible moves,
the possible positions and the set.
|
void |
Game.doMove(java.util.List<Node> aPlayerMove)
Checks if the list of blocks received are in the hand of the player.
|
java.util.List<Node> |
Board.giveHint(java.util.List<Node> possibleMoves,
java.util.List<Node> currentSet,
Block aBlock)
Fills in a block to find out which positions offer a valid move.
|
java.util.List<Node> |
Board.giveHint(java.util.List<Node> possibleMoves,
java.util.List<Node> currentSet,
Block aBlock)
Fills in a block to find out which positions offer a valid move.
|
boolean |
Board.isValid(java.util.List<Node> aListOfMoves)
Checks if a move a Player does is valid by checking if all blocks of a
move are placed in the same row and if the color or the shape is the same
according to the rules.
|
boolean |
Board.isValidConnected(java.util.List<Node> aListOfBlock)
Looks if the all the blocks in aListOfBlocks can be reached
by accasing the neighbors going strictly left and right or up and down.
|
static void |
Board.printNodeList(java.util.List<Node> aNodeList)
Prints the list of empty nodes to the console.
|
void |
Player.removeBlocksFromHand(java.util.List<Node> aList)
Removes a block from a players hand.
|
void |
Board.setEmptySpaces(java.util.List<Node> aNewEmptySpaceList)
Setter for empty spaces on the board.
|
void |
Game.setFirstPlayer(java.util.Map<Player,java.util.List<Node>> firstSet)
Sets the first player and does the move that was worth the most points.
|
void |
HumanTUIPlayer.setMove(java.util.List<Node> aNode)
Does a move on the board with a list of nodes.
|
void |
ComputerPlayer.setMove(java.util.List<Node> aNode)
Do a particular move.
|
void |
Board.setStones(java.util.List<Node> aNodeList)
Makes a copy of the placedBlock list and empty spaces list.
|
java.util.Map<Player,java.util.List<Node>> |
Game.startingPlayer(java.util.Map<Player,java.util.List<Node>> aMapWithFirstMoves)
Receives the first move of all the players and determine which player
should start by calculation the scores of each move.
|
static java.lang.String |
Board.toString(java.util.List<Node> aListOfPlacedBlocks,
java.util.List<Node> aListOfPossibleMoves)
Prints a string representation of the current state of the board.
|
static java.lang.String |
Board.toString(java.util.List<Node> aListOfPlacedBlocks,
java.util.List<Node> aListOfPossibleMoves)
Prints a string representation of the current state of the board.
|


This example shows how you can use Widget's plugin infrastructure to add additional features to an existing widget.
We create an IO plugin class for Overlay
called StdModIOPlugin
. The plugin adds IO capabilities to the Overlay, bound to one of its standard module sections (header, body or footer).


Let's play!
Rules:
Rules:
Ping Pong will count up to your number from 1 with the following exceptions:
- Numbers divisible by 3 become "ping"
- Numbers divisible by 5 become "pong"
- Numbers divisible by 3 and 5 become "pingpong"


Computation times¶
00:12.110 total execution time for auto_examples files:
Quantitative ESR ( |
00:03.870 |
0.0 MB |
Using the DCCT function ( |
00:02.175 |
0.0 MB |
Plotting Routines ( |
00:01.250 |
0.0 MB |
BSA UV-Vis Calibration ( |
00:00.925 |
0.0 MB |
Manipulation of UV-Vis data ( |
00:00.905 |
0.0 MB |
ppm Example ( |
00:00.502 |
0.0 MB |
Simple Cary UV-Vis loading ( |
00:00.490 |
0.0 MB |
Bruker cw ESR Data ( |
00:00.465 |
0.0 MB |
Basic Slicing/Filtering Example ( |
00:00.387 |
0.0 MB |
Simple Convolution Example ( |
00:00.307 |
0.0 MB |
Fitting Data (Nonlinear + Symbolic) ( |
00:00.303 |
0.0 MB |
Fit Using Bounds ( |
00:00.246 |
0.0 MB |
Fit complex data ( |
00:00.205 |
0.0 MB |
Polynomial Fitting ( |
00:00.080 |
0.0 MB |


Image Search Abstraction Layer
User Stories
- I can get the image URLs, alt text and page urls for a set of images relating to a given search string.
- I can paginate through the responses by adding a ?offset=2 parameter to the URL.
- I can get a list of the most recently submitted search strings.
Sample request
https://smoore-imagesearch.herokuapp.com/imagesearch/landscape?offset=2
Sample results
[
{
"url": "http://upload.wikimedia.org/wikipedia/commons/d/de/Derbyshire_Landscape.jpg",
"snippet": "Description Derbyshire Landscape.jpg",
"thumbnail": "https://tse2.mm.bing.net/th?id=OIP.M7f8839ebf460b71bcd94460ddf11866co0&pid=Api",
"context": "commons.wikimedia.org/wiki/File:Derbyshire_Landscape.jpg"
},
{
...
},
...
]
Sample latest searches request
https://smoore-imagesearch.herokuapp.com/latest/imagesearch/


{{!
Provide a single or multiple drop-down select control.
Parameters:
label, name, errorMessage (String)
required, multiple (Boolean)
options (Array[Object]). Specifies each selection. Can have fields label, value, selected.
Example: [{ label: "4.0+", value: "4" } { label: "3.0-3.9", value: "3", selected: true }]
Setting multiple to true makes this a multi-selection controller.
Name is optional and defaults to label. errorMessage and required are optional.
Here's what this template might look like when instantiated:


Guidelines
Here are some guidelines for people who want to contribute their code to this software. There is also a step-by-step tutorial available which covers many of these same guidelines.
Decide what to base your work on.
In general, always base your work on the oldest branch that your change is relevant to.
-
A bugfix should be based on
maint
in general. If the bug is not present inmaint
, base it onmaster
. For a bug that’s not yet inmaster
, find the topic that introduces the regression, and base your work on the tip of the topic. -
A new feature should be based on
master
in general. If the new feature depends on a topic that is inseen
, but not inmaster
, base your work on the tip of that topic. -
Corrections and enhancements to a topic not yet in
master
should be based on the tip of that topic. If the topic has not been merged tonext
, it’s alright to add a note to squash minor corrections into the series. -
In the exceptional case that a new feature depends on several topics not in
master
, start working onnext
orseen
privately and send out patches for discussion. Before the final merge, you may have to wait until some of the dependent topics graduate tomaster
, and rebase your work. -
Some parts of the system have dedicated maintainers with their own repositories (see the section "Subsystems" below). Changes to these parts should be based on their trees.
To find the tip of a topic branch, run git log --first-parent
master..seen
and look for the merge commit. The second parent of this
commit is the tip of the topic branch.
Make separate commits for logically separate changes.
  It is a good discipline.
Give an explanation for the change(s) that is detailed enough so that people can judge if it is good thing to do, without reading the actual patch text to determine how well the code does what the explanation promises to do.
 That being said, patches which plainly describe the things that help reviewers check the patch, and future maintainers understand the code, are the most beautiful patches. Descriptions that summarize the point in the subject well, and describe the motivation for the change, the approach taken by the change, and if relevant how this differs substantially from the prior version, are all good things to have.
Make sure that you have tests for the bug you are fixing. See
t/README
for guidance.
When adding a new feature, make sure that you have new tests to show the feature triggers the new behavior when it should, and to show the feature does not trigger when it shouldn’t. After any code change, make sure that the entire test suite passes.
If you have an account at GitHub (and you can get one for free to work on open source projects), you can use their Travis CI integration to test your changes on Linux, Mac (and hopefully soon Windows). See GitHub-Travis CI hints section for details.
Do not forget to update the documentation to describe the updated behavior and make sure that the resulting documentation set formats well (try the Documentation/doc-diff script).
We currently have a liberal mixture of US and UK English norms for spelling and grammar, which is somewhat unfortunate. A huge patch that touches the files all over the place only to correct the inconsistency is not welcome, though. Potential clashes with other changes that can result from such a patch are not worth it. We prefer to gradually reconcile the inconsistencies in favor of US English, with small and easily digestible patches, as a side effect of doing some other real work in the vicinity (e.g. rewriting a paragraph for clarity, while turning en_UK spelling to en_US). Obvious typographical fixes are much more welcomed ("teh → "the"), preferably submitted as independent patches separate from other documentation changes.
Oh, another thing. We are picky about whitespaces. Make sure your
changes do not trigger errors with the sample pre-commit hook shipped
in templates/hooks--pre-commit
. To help ensure this does not happen,
run git diff --check
on your changes before you commit.
Describe your changes well.
The first line of the commit message should be a short description (50 characters is the soft limit, see DISCUSSION in git-commit(1)), and should skip the full stop. It is also conventional in most cases to prefix the first line with "area: " where the area is a filename or identifier for the general area of the code being modified, e.g.
-
doc: clarify distinction between sign-off and pgp-signing
-
githooks.txt: improve the intro section
If in doubt which identifier to use, run git log --no-merges
on the
files you are modifying to see the current conventions.
It’s customary to start the remainder of the first line after "area: " with a lower-case letter. E.g. "doc: clarify…", not "doc: Clarify…", or "githooks.txt: improve…", not "githooks.txt: Improve…".
The body should provide a meaningful commit message, which:
-
explains the problem the change tries to solve, i.e. what is wrong with the current code without the change.
-
justifies the way the change solves the problem, i.e. why the result with the change is better.
-
alternate solutions considered but discarded, if any.
Describe your changes in imperative mood, e.g. "make xyzzy do frotz" instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy to do frotz", as if you are giving orders to the codebase to change its behavior. Try to make sure your explanation can be understood without external resources. Instead of giving a URL to a mailing list archive, summarize the relevant points of the discussion.
If you want to reference a previous commit in the history of a stable branch, use the format "abbreviated hash (subject, date)", like this:
Commit f86a374 (pack-bitmap.c: fix a memleak, 2015-03-30)
noticed that ...
The "Copy commit summary" command of gitk can be used to obtain this
format (with the subject enclosed in a pair of double-quotes), or this
invocation of git show
:
git show -s --pretty=reference <commit>
or, on an older version of Git without support for --pretty=reference:
git show -s --date=short --pretty='format:%h (%s, %ad)' <commit>
Generate your patch using Git tools out of your commits.
Git based diff tools generate unidiff which is the preferred format.
You do not have to be afraid to use -M
option to git diff
or
git format-patch
, if your patch involves file renames. The
receiving end can handle them just fine.
Please make sure your patch does not add commented out debugging code,
or include any extra files which do not relate to what your patch
is trying to achieve. Make sure to review
your patch after generating it, to ensure accuracy. Before
sending out, please make sure it cleanly applies to the master
branch head. If you are preparing a work based on "next" branch,
that is fine, but please mark it as such.
Sending your patches.
Before sending any patches, please note that patches that may be
security relevant should be submitted privately to the Git Security
mailing list
[The Git Security mailing list<EMAIL_ADDRESS>, instead of the public mailing list.
Learn to use format-patch and send-email if possible. These commands are optimized for the workflow of sending patches, avoiding many ways your existing e-mail client that is optimized for "multipart/*" mime type e-mails to corrupt and render your patches unusable.
People on the Git mailing list need to be able to read and comment on the changes you are submitting. It is important for a developer to be able to "quote" your changes, using standard e-mail tools, so that they may comment on specific portions of your code. For this reason, each patch should be submitted "inline" in a separate message.
Multiple related patches should be grouped into their own e-mail thread to help readers find all parts of the series. To that end, send them as replies to either an additional "cover letter" message (see below), the first patch, or the respective preceding patch.
If your log message (including your name on the Signed-off-by line) is not writable in ASCII, make sure that you send off a message in the correct encoding.
|
Warning
|
Be wary of your MUAs word-wrap corrupting your patch. Do not cut-n-paste your patch; you can lose tabs that way if you are not careful. |
It is a common convention to prefix your subject line with [PATCH]. This lets people easily distinguish patches from other e-mail discussions. Use of markers in addition to PATCH within the brackets to describe the nature of the patch is also encouraged. E.g. [RFC PATCH] (where RFC stands for "request for comments") is often used to indicate a patch needs further discussion before being accepted, [PATCH v2], [PATCH v3] etc. are often seen when you are sending an update to what you have previously sent.
The git format-patch
command follows the best current practice to
format the body of an e-mail message. At the beginning of the
patch should come your commit message, ending with the
Signed-off-by: lines, and a line that consists of three dashes,
followed by the diffstat information and the patch itself. If
you are forwarding a patch from somebody else, optionally, at
the beginning of the e-mail message just before the commit
message starts, you can put a "From: " line to name that person.
To change the default "[PATCH]" in the subject to "[<text>]", use
git format-patch --subject-prefix=<text>
. As a shortcut, you
can use --rfc
instead of --subject-prefix="RFC PATCH"
, or
-v <n>
instead of --subject-prefix="PATCH v<n>"
.
You often want to add additional explanation about the patch,
other than the commit message itself. Place such "cover letter"
material between the three-dash line and the diffstat. For
patches requiring multiple iterations of review and discussion,
an explanation of changes between each iteration can be kept in
Git-notes and inserted automatically following the three-dash
line via git format-patch --notes
.
Do not attach the patch as a MIME attachment, compressed or not. Do not let your e-mail client send quoted-printable.  Many popular e-mail applications will not always transmit a MIME attachment as plain text, making it impossible to comment on your code. A MIME attachment also takes a bit more time to process. This does not decrease the likelihood of your MIME-attached change being accepted, but it makes it more likely that it will be postponed.
Exception: If your mailer is mangling patches then someone may ask you to re-send them using MIME, that is OK.
Do not PGP sign your patch. Most likely, your maintainer or other people on the list would not have your PGP key and would not bother obtaining it anyway. Your patch is not judged by who you are; a good patch from an unknown origin has a far better chance of being accepted than a patch from a known, respected origin that is done poorly or does incorrect things.
If you really really really really want to do a PGP signed
patch, format it as "multipart/signed", not a text/plain message
that starts with -----BEGIN PGP SIGNED MESSAGE-----
. That is
not a text/plain, it’s something else.
As mentioned at the beginning of the section, patches that may be
security relevant should not be submitted to the public mailing list
mentioned below, but should instead be sent privately to the Git
Security mailing list
[security-ml]
.
Send your patch with "To:" set to the mailing list, with "cc:" listing
people who are involved in the area you are touching (the git
contacts
command in contrib/contacts/
can help to
identify them), to solicit comments and reviews.
After the list reached a consensus that it is a good idea to apply the
patch, re-send it with "To:" set to the maintainer
[The current maintainer<EMAIL_ADDRESS>and "cc:" the
list
[The mailing list<EMAIL_ADDRESS>for inclusion.
Do not forget to add trailers such as Acked-by:
, Reviewed-by:
and
Tested-by:
lines as necessary to credit people who helped your
patch.
Certify your work by adding your "Signed-off-by: " line
To improve tracking of who did what, we’ve borrowed the "sign-off" procedure from the Linux kernel project on patches that are being emailed around. Although core Git is a lot smaller project it is a good discipline to follow it.
The sign-off is a simple line at the end of the explanation for the patch, which certifies that you wrote it or otherwise have the right to pass it on as an open-source patch. The rules are pretty simple: if you can certify the below D-C-O:
By making a contribution to this project, I certify that:
-
The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or
-
The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or
-
The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.
-
I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved.
then you just add a line saying
Signed-off-by: Random J Developer<EMAIL_ADDRESS>This line can be automatically added by Git if you run the git-commit command with the -s option.
Notice that you can place your own Signed-off-by: line when forwarding somebody else’s patch with the above rules for D-C-O. Indeed you are encouraged to do so. Do not forget to place an in-body "From: " line at the beginning to properly attribute the change to its true author (see (2) above).
Also notice that a real name is used in the Signed-off-by: line. Please don’t hide your real name.
If you like, you can put extra tags at the end:
-
Reported-by:
is used to credit someone who found the bug that the patch attempts to fix. -
Acked-by:
says that the person who is more familiar with the area the patch attempts to modify liked the patch. -
Reviewed-by:
, unlike the other tags, can only be offered by the reviewer and means that she is completely satisfied that the patch is ready for application. It is usually offered only after a detailed review. -
Tested-by:
is used to indicate that the person applied the patch and found it to have the desired effect.
You can also create your own tag or use one that’s in common usage such as "Thanks-to:", "Based-on-patch-by:", or "Mentored-by:".
Subsystems with dedicated maintainers
Some parts of the system have dedicated maintainers with their own repositories.
-
git-gui/
comes from git-gui project, maintained by Pratyush Yadav:https://github.com/prati0100/git-gui.git
-
gitk-git/
comes from Paul Mackerras’s gitk project:git://ozlabs.org/~paulus/gitk
-
po/
comes from the localization coordinator, Jiang Xin:https://github.com/git-l10n/git-po/
Patches to these parts should be based on their trees.
An ideal patch flow
Here is an ideal patch flow for this project the current maintainer suggests to the contributors:
-
You come up with an itch. You code it up.
-
Send it to the list and cc people who may need to know about the change.
The people who may need to know are the ones whose code you are butchering. These people happen to be the ones who are most likely to be knowledgeable enough to help you, but they have no obligation to help you (i.e. you ask for help, don’t demand).
git log -p -- $area_you_are_modifying
would help you find out who they are. -
You get comments and suggestions for improvements. You may even get them in an "on top of your change" patch form.
-
Polish, refine, and re-send to the list and the people who spend their time to improve your patch. Go back to step (2).
-
The list forms consensus that the last round of your patch is good. Send it to the maintainer and cc the list.
-
A topic branch is created with the patch and is merged to
next
, and cooked further and eventually graduates tomaster
.
In any time between the (2)-(3) cycle, the maintainer may pick it up
from the list and queue it to seen
, in order to make it easier for
people play with it without having to pick up and apply the patch to
their trees themselves.
Know the status of your patch after submission
-
You can use Git itself to find out when your patch is merged in master.
git pull --rebase
will automatically skip already-applied patches, and will let you know. This works only if you rebase on top of the branch in which your patch has been merged (i.e. it will not tell you if your patch is merged inseen
if you rebase on top of master). -
Read the Git mailing list, the maintainer regularly posts messages entitled "What’s cooking in git.git" and "What’s in git.git" giving the status of various proposed changes.
GitHub-Travis CI hints
With an account at GitHub (you can get one for free to work on open source projects), you can use Travis CI to test your changes on Linux, Mac (and hopefully soon Windows). You can find a successful example test build here: https://travis-ci.org/git/git/builds/120473209
Follow these steps for the initial setup:
-
Fork https://github.com/git/git to your GitHub account. You can find detailed instructions how to fork here: https://help.github.com/articles/fork-a-repo/
-
Open the Travis CI website: https://travis-ci.org
-
Press the "Sign in with GitHub" button.
-
Grant Travis CI permissions to access your GitHub account. You can find more information about the required permissions here: https://docs.travis-ci.com/user/github-oauth-scopes
-
Open your Travis CI profile page: https://travis-ci.org/profile
-
Enable Travis CI builds for your Git fork.
After the initial setup, Travis CI will run whenever you push new changes to your fork of Git on GitHub. You can monitor the test state of all your branches here: https://travis-ci.org/<Your GitHub handle>/git/branches
If a branch did not pass all test cases then it is marked with a red cross. In that case you can click on the failing Travis CI job and scroll all the way down in the log. Find the line "←- Click here to see detailed test output!" and click on the triangle next to the log line number to expand the detailed test output.  This will trigger a new Travis CI build to ensure all tests pass.
MUA specific hints
Some of patches I receive or pick up from the list share common patterns of breakage. Please make sure your MUA is set up properly not to corrupt whitespaces.
See the DISCUSSION section of git-format-patch(1) for hints on checking your patch by mailing it to yourself and applying with git-am(1).
While you are at it, check the resulting commit log message from a trial run of applying the patch. If what is in the resulting commit is not exactly what you would want to see, it is very likely that your maintainer would end up hand editing the log message when he applies your patch. Things like "Hi, this is my first patch.\n", if you really want to put in the patch e-mail, should come after the three-dash line that signals the end of the commit message.
Pine
(Johannes Schindelin)
I don't know how many people still use pine, but for those poor
souls it may be good to mention that the quell-flowed-text is
needed for recent versions.
... the "no-strip-whitespace-before-send" option, too. AFAIK it
was introduced in 4.60.
(Linus Torvalds)
And 4.58 needs at least this.
diff-tree 8326dd8350be64ac7fc805f6563a1d61ad10d32c (from e886a61f76edf5410573e92e38ce22974f9c40f1)
Author: Linus Torvalds<EMAIL_ADDRESS>Date: Mon Aug 15 17:23:51 2005 -0700
Fix pine whitespace-corruption bug
There's no excuse for unconditionally removing whitespace from
the pico buffers on close.
diff --git a/pico/pico.c b/pico/pico.c
--- a/pico/pico.c
+++ b/pico/pico.c
@@ -219,7 +219,9 @@ PICO *pm;
switch(pico_all_done){ /* prepare for/handle final events */
case COMP_EXIT : /* already confirmed */
packheader();
+#if 0
stripwhitespace();
+#endif
c |= COMP_EXIT;
break;
(Daniel Barkalow)
> A patch to SubmittingPatches, MUA specific help section for
> users of Pine 4.63 would be very much appreciated.
Ah, it looks like a recent version changed the default behavior to do the
right thing, and inverted the sense of the configuration option. (Either
that or Gentoo did it.) So you need to set the
"no-strip-whitespace-before-send" option, unless the option you have is
"strip-whitespace-before-send", in which case you should avoid checking
it.
Thunderbird, KMail, GMail
See the MUA-SPECIFIC HINTS section of git-format-patch(1).
Gnus
"|" in the *Summary*
buffer can be used to pipe the current
message to an external program, and this is a handy way to drive
git am
. However, if the message is MIME encoded, what is
piped into the program is the representation you see in your
*Article*
buffer after unwrapping MIME. This is often not what
you would want for two reasons. It tends to screw up non ASCII
characters (most notably in people’s names), and also
whitespaces (fatal in patches). Running "C-u g" to display the
message in raw form before using "|" to run the pipe can work
this problem around.


Monitor
Actions
Reverse
Crash
Wait
Monitor
subscribe
unsubscribe
snapshot
Info
Sessions:
TimeUnits Elapsed:
Objects:
Event Queue:
Events
Errors


The first recorded use of the word 'pizza' occurred in 997 AD. In the late 1600's, pizza as we know it evolved with the usage of tomato sauce.
In 1830 the world's first pizzeria opened in Italy. Seventy-five years later, the first licensed American pizzaria was established in New York. Vita Bella opened in 1999. While we are perfecting the art of crafting pizzas, your mouth is salivating at the prospect of biting into one of our delicious pizzas. If you want to make this dream a reality, please contact us right away.


Apache Flink Kubernetes Operator 1.2.0 Release Announcement
October 7, 2022 - Gyula Fora (@GyulaFora)We are proud to announce the latest stable release of the operator. The 1.2.0 release adds support for the Standalone Kubernetes deployment mode and includes several improvements to the core logic.
Release Highlights #
- Standalone deployment mode support
- Improved upgrade flow
- Readiness and liveness probes
- Flexible job jar handling
Standalone deployment mode support #
Until now the operator relied exclusively on Flink’s built-in Native Kubernetes integration to deploy and manage Flink clusters. When using the Native deployment mode the Flink cluster communicates directly with Kubernetes to allocate/deallocate TaskManager resources on the fly. While this leads to a very simple deployment model, in some environments it also means higher security exposure as the user code running on the Flink cluster may gain the same Kubernetes access privileges.
Flink Kubernetes Operator 1.2.0 brings Standalone mode support for FlinkDeployment resources.
When using the standalone mode, the operator itself sets up the Job and TaskManager resources for the Flink cluster. Flink processes then run without any need for Kubernetes access. In fact in this mode the Flink cluster itself is unaware that it is running in a Kubernetes environment. If unknown or external code is being executed on the Flink cluster then Standalone mode adds another layer of security.
The default deployment mode is Native. Native deployment mode remains the recommended mode for standard operator use and when running your own Flink jobs.
The deployment mode can be set using the mode
field in the deployment spec.
apiVersion: flink.apache.org/v1beta1
kind: FlinkDeployment
...
spec:
...
mode: native/standalone
Improved upgrade flow #
There have been a number of important changes that improve the job submission and upgrade flow. The operator now distinguishes configuration & spec changes that do not require the redeployment of the Flink cluster resources (such as setting a new periodic savepoint interval). These improvements now avoid unnecessary job downtime in many cases.
Leveraging the standalone deployment mode the operator now also supports rescaling jobs directly using Flink’s reactive scheduler. When changing the parallelism of an application FlinkDeployment with mode: standalone
set and scheduler-mode: reactive
in the flinkConfiguration
the operator will simply increase the number of TaskManagers to match the new parallelism and let Flink do the scaling automatically (reactively). Same as with the reactive scaling itself, this is considered to be an experimental feature.
There are also some important fixes to problems that might occur when switching between Flink versions or using the stateless upgrade mode.
Readiness and Liveness probes #
From an operational perspective it is very important to be able to determine the health of the Kubernetes Operator process. The operator now exposes a health endpoint by default together with a liveness and readiness probe.
Flexible job jar handling #
The 1.2.0 release now makes the jobSpec.jarURI parameter optional to allow users to run jobs using dependencies that are already bundled in the Flink classpath.
This can be especially valuable in session deployments when multiple jobs, reusing the same artifacts, are deployed with different configurations.
Release Resources #
The source artifacts and helm chart are now available on the updated Downloads page of the Flink website.
$ helm repo add flink-kubernetes-operator-1.2.0 https://archive.apache.org/dist/flink/flink-kubernetes-operator-1.2.0/
$ helm install flink-kubernetes-operator flink-kubernetes-operator-1.2.0/flink-kubernetes-operator --set webhook.create=false
You can also find official Kubernetes Operator Docker images of the new version on [Dockerhub](https://hub.docker.com/r/apache/flink-kubernetes-operator).
For more details, check the updated documentation and the release notes. We encourage you to download the release and share your feedback with the community through the Flink mailing lists or JIRA.
List of Contributors #
Aitozi, Avocadomaster, ConradJam, Dylan Meissner, Gabor Somogyi, Gaurav Miglani, Gyula Fora, Jeesmon Jacob, Joao Ubaldo, Marton Balassi, Matyas Orhidi, Maximilian Michels, Nicholas Jiang, Peter Huang, Robson Roberto Souza Peixoto, Thomas Weise, Tim, Usamah Jassat, Xin Hao, Yaroslav Tkachenko


How to calculate BOLUS dose
Carb ratio: covers the amout of carbs that are going to be eaten
Grams of carbs / Your Carb Ratio = units of insulin
Correction factor: covers the blood glucose if its high before the meal
(Blood glucose - Target) / Sensitivity = units of insulin


Create QR Code
URL of the content
Id (optional)
Generate QR Image
QR Code
Click on the image to copy it and embed it in the document. You can test it right now.


|
Objective-C++ Preprocessor
5.0 with ARC & GC
C++ classes to enhance syntax and manage reference counting.
|
#import <objsql.h>
Instance Methods | |
| (id) | - initPath: |
| (OOStringArray) | - registerSubclassesOf: |
| (void) | - registerTableClassesNamed: |
| (OOArray< OOMetaData * >) | - tablesRelatedByNaturalJoinFrom: |
| (OOMetaData *) | - tableMetaDataForClass: |
| (BOOL) | - exec: |
| (OOString) | - stringForSql: |
| (id) | - copyJoinKeysFrom:to: |
| (OOArray< id >) | - select:intoClass:joinFrom: |
| (OOArray< id >) | - select:intoClass: |
| (OOArray< id >) | - select: |
| (long long) | - rowIDForRecord: |
| (long long) | - lastInsertRowID |
| (int) | - insertArray: |
| (int) | - deleteArray: |
| (int) | - insert: |
| (int) | - delete: |
| (int) | - update: |
| (int) | - indate: |
| (int) | - upsert: |
| (int) | - commit |
| (int) | - commitTransaction |
| (int) | - rollback |
| (OOString) | - whereClauseFor:values:qualifyNulls: [implementation] |
| (BOOL) | - prepareSql:joinFrom:toTable: [implementation] |
Class Methods | |
| (OODatabase *) | + sharedInstance |
| (OODatabase *) | + sharedInstanceForPath: |
| (BOOL) | + exec: |
| (OOArray< id >) | + select:intoClass:joinFrom: |
| (OOArray< id >) | + select:intoClass: |
| (OOArray< id >) | + select: |
| (int) | + insertArray: |
| (int) | + deleteArray: |
| (int) | + insert: |
| (int) | + delete: |
| (int) | + update: |
| (int) | + indate: |
| (int) | + upsert: |
| (int) | + commit |
| (int) | + rollback |
| (int) | + commitTransaction |
Public Attributes | |
| OOArray< OOValueDictionary > | transaction |
| OOArray< OOValueDictionary > | results |
| int | errcode |
| int | updateCount |
| char * | errmsg |
| OOString | lastSQL |
Protected Attributes | |
| OODictionary< OOMetaData * > | tableMetaDataByClassName |
| OOReference< OOAdaptor * > | adaptor |
Simple persistence class for Objective-C objects using a "sqlite" database. Instances a class are automatically bound to a table with the class name for insert, update and delete.
A table with the same name as the class is created automatically when you perform any operation on instances of that class with columns corresponding to the instance variables of the class except those which begin with the character "_". If an instance variable starts with an upper case letter it will be indexed.
To update a record, fetch it and call the update: method passing it in as the argument to save it's preious values. You can then modify it and call commit to update it's record. Delete operations on objects also accumulate and need to be commited to take effect.
| + (int) commit |
| - (int) commit |
| + (int) commitTransaction |
| - (int) commitTransaction |
| - (id) copyJoinKeysFrom: | (id) | parent | |
| to: | (id) | newChild | |
| + (int) delete: | (id) | record |
| - (int) delete: | (id) | object |
| + (int) deleteArray: | (const OOArray<id> &) | objects |
| - (int) deleteArray: | (const OOArray< id > &) | objects |
| + (BOOL) exec: | (cOOString) | fmt | |
| , | ... | ||
| - (BOOL) exec: | (cOOString) | sql | |
| , | ... | ||
| + (int) indate: | (id) | record |
| - (int) indate: | (id) | object |
| - (id) initPath: | (cOOString) | path |
Designated initialiser for OODatabase instances. Generally only the shared instance is used and the OODatabase class object is messaged instead.
| + (int) insert: | (id) | record |
| - (int) insert: | (id) | object |
| + (int) insertArray: | (const OOArray<id> &) | objects |
| - (int) insertArray: | (const OOArray< id > &) | objects |
| - (long long) lastInsertRowID |
|
implementation |
| - (OOStringArray) registerSubclassesOf: | (Class) | recordSuperClass |
| - (void) registerTableClassesNamed: | (cOOStringArray) | classes |
Register a list of classes before using them so OODatabase can determine the relationships between them.
| + (int) rollback |
| - (int) rollback |
| - (long long) rowIDForRecord: | (id) | record |
| + (OODatabase *) sharedInstance |
By default database file is "objsql.db" in the user/application's "Documents" directory and a single shared OODatabase instance used for all db operations.
| + (OODatabase *) sharedInstanceForPath: | (cOOString) | path |
| - (OOMetaData *) tableMetaDataForClass: | (Class) | recordClass |
Find/create an instance of the OOMetaData class which describes a record class and its associated table. If the table does not exist it will be created along with indexes for columns/ivars which have upper case names for use in joins. Details of the tables parameters can be controlled by using methods in the OOTableCustomisation protool. If it does not exist a meta table class which prepresents OOMetaData records themselves is also created from which the list of all registered tables can be selected.
| - (OOArray< OOMetaData * >) tablesRelatedByNaturalJoinFrom: | (id) | record |
| + (int) update: | (id) | record |
Call this method if you intend to make changes to the record object and save them to the database. This takes a snapshot of the previous values to use as a key for the update operation when "commit" is called. Returns the total number of outstanding inserts/updates/deletes.
| - (int) update: | (id) | object |
| + (int) upsert: | (id) | record |
| - (int) upsert: | (id) | object |
|
implementation |
|
protected |
| - (OOArray<OOValueDictionary >) results |
|
protected |
| - (OOArray<OOValueDictionary >) transaction |


Qpid Proton Python API Documentation¶
The Proton module provides a Python 2.7 and 3.x API for Qpid Proton. It enables a developer to write Python applications that send and receive AMQP messages.
Modules¶
About AMQP and the Qpid Proton Python API¶
Key API Features¶
Event-driven API
SSL/TLS secured communication
SASL authentication
Automatic reconnect and failover
Seamless conversion between AMQP and Python data types
AMQP 1.0
Basic API Concepts¶
The Qpid Python client API and library allows applications to send and receive AMQP messages. See API Overview for a more detailed explanation.
Containers¶
Messages are transferred between connected peers (or nodes) using senders and receivers. Each sender
or receiver is established over a connection. Each connection is established between two unique containers,
the entry point for the API. The container class proton.reactor.Container
is found in the proton.reactor
module.
Connections¶
A connection object tracks the status of an AMQP connection. For applications which don’t require either
authorization or encryption, these may be automatically created by convenience methods
proton.reactor.Container.create_sender()
and/or proton.reactor.Container.create_receiver()
.
However, for applications which do require either of these services, a connection object should be created
using the convenience method proton.reactor.Container.connect()
, providing the required parameters.
This object should then be passed to the convenience methods proton.reactor.Container.create_sender()
and/or proton.reactor.Container.create_receiver()
as needed. The connection class may be found at
proton.Connection
.
Senders¶
The peer that sends messages uses a sender to send messages, which includes the target queue or topic which is
to receive the messages. The sender may be found at proton.Sender
. Note that senders are most commonly
obtained by using the convenience method proton.reactor.Container.create_sender()
.
Receivers¶
The peer that receives messages uses a receiver to receive messages, and includes a source queue or topic from
which to receive messages. The receiver may be found at proton.Receiver
. Note that senders are most commonly
obtained by using the convenience method proton.reactor.Container.create_receiver()
.
Message Delivery¶
The process of sending a message is known as delivery. Each sent message has a delivery object which tracks the
status of the message as it is sent from the sender to the receiver. This also includes actions such as settling the
delivery (ie causing the delivery status to be forgotten when it is no longer needed). The delivery class may be found
at proton.Delivery
. The delivery object is most commonly obtained
when a message-related event occurs through the event object. See Event Handlers below.
Event Handlers¶
A handler is a class that handles events associated with the sending and receiving of messages. This includes
callbacks for events such as the arrival of a new message, error conditions that might arise, and the closing
of the connection over which messages are sent. An application developer must handle some key events to
successfully send and receive messages. When an event handler callback is called by the library, an Event object is
passed to it which contains an object associated with the event. For example,
when a message is received, the event object will have the property event.message
by which the message itself may
be obtained. See proton.Event
for more details.
The following are some of the important event callbacks that may be implemented by a developer:
- on_start(): This indicates that the event loop in the container has started, and that a new sender and/or
receiver may now be created.
To send a message, the following events may need to be handled:
- on_sendable(): This callback indicates that send credit has now been set by the receiver, and that a message may
now be sent.
on_accepted(): This callback indicates that a message has been received and accepted by the receiving peer.
To receive a message, the following event may need to be handled:
- on_message(): This callback indicates that a message has been received. The message and its delivery object may
be retreived, and if needed, the message can be either accepted or rejected.
Many other events exist for the handling of transactions and other message events and errors, and if present in your handler will be called as the corresponding events arise. See the Tutorial for examples of handling some other events.
Several event handlers are provided which provide default behavior for most events. These may be found in the
proton.handlers
module. The proton.handlers.MessagingHandler
is the most commonly used handler for
non-transactional applications. Developers would typically directly inherit from this handler to provide the
application’s event behavior, and override callbacks as needed to provide additional behavior they may require.
AMQP types¶
The types defined by the AMQP specification are mapped to either native Python types or to special proton classes which represent the AMQP type. See AMQP Types for a summary.
Examples¶
Several examples may be found in the Apache Qpid Proton Examples whcih illustrate the techniques and concepts of sending messages. They are also present in the source. These make an excellent starting point for developers new to this API. Make sure to read the README file, which gives instructions on how to run them and a brief explanation of each example.


Home
(current)
About
Services
Our Work
Contacts
John Doe
Profile
Account Settings
Newsletter
Sign Out
Sign up
Your name
Your email
New password
Repeat password
Subscribe to updates
Register