---
layout: page
title: Publications
permalink: /publications/
published: false
---
Journal Articles
- Ren, Y., Bayrak, A., Papalambros, P. Y. (2016). Ecoracer: Optimal Design and Control of Electric Vehicles Using Human Game Players. Journal of Mechanical Design, 138, 061407.
pdf
- Burnap, A., Pan, Y., Liu, Y., Ren, Y., Lee, H., Gonzalez, R., Papalambros, P. Y. (2016). Improving Design Preference Prediction Accuracy using Feature Learning. Journal of Mechanical Design.
(accepted)
pdf
- Bayrak, A., Ren, Y., Papalambros, P. Y. (2016). Topology Generation for Hybrid Electric Vehicle Architecture Design. Journal of Mechanical Design.
(accepted)
pdf
- Kang, N., Ren, Y., Feinberg, F. M., Papalambros, P. Y. (2016). Public investment and electric vehicle design: a model-based market analysis framework with application to a USA-China comparison study. Design Science, 2, e6.
pdf
- Burnap, A., Ren, Y., Gerth, R., Papazoglou, G., Gonzalez, R., Papalambros, P. Y. (2015). When crowdsourcing fails: A study of expertise on crowdsourced design evaluation. Journal of Mechanical Design, 137(3), 031101.
pdf
- Ren, Y., Papalambros, P. Y. (2011). A Design Preference Elicitation Query as an Optimization Process. Journal of Mechanical Design, 133, 111004.
pdf
conference
- Ren, Y., Bayrak, A. E., Papalambros, P. Y. (2015). ecoRacer: Game-Based Optimal Electric Vehicle Design and Driver Control Using Human Players. In ASME 2015 International Design Engineering Technical Conferences and Computers and Information in Engineering Conference (pp. V02AT03A009-V02AT03A009). American Society of Mechanical Engineers.
pdf
, data
, erratum
, best paper award in design automation
- Kang, N., Emmanoulopoulos, M., Ren, Y., Feinberg, F. M., Papalambros, P. Y., others. (2015). A Framework for Quantitative Analysis of Government Policy Influence on Electric Vehicle Market. In Proceedings of the 20th International Conference on Engineering Design (ICED 15) (Vol. 5).
pdf
- Bayrak, A. E., Ren, Y., Papalambros, P. Y. (2014). Optimal Dual-Mode Hybrid Electric Vehicle Powertrain Architecture Design for a Variety of Loading Scenarios. In ASME 2014 International Design Engineering Technical Conferences and Computers and Information in Engineering Conference (pp. V003T01A005-V003T01A005). American Society of Mechanical Engineers.
pdf
- Ren, Y., Papalambros, P. Y. (2014). Enhanced Adaptive Choice-Based Conjoint Analysis Incorporating Engineering Knowledge. In ASME 2014 International Design Engineering Technical Conferences and Computers and Information in Engineering Conference (pp. V02AT03A033-V02AT03A033). American Society of Mechanical Engineers.
pdf
- Burnap, A., Ren, Y., Lee, H., Gonzalez, R., Papalambros, P. Y. (2014). Improving Preference Prediction Accuracy With Feature Learning. In ASME 2014 International Design Engineering Technical Conferences and Computers and Information in Engineering Conference (pp. V02AT03A012-V02AT03A012). American Society of Mechanical Engineers.
pdf
- Ren, Y., Scott, C., Papalambros, P. Y. (2013). A scalable preference elicitation algorithm using group generalized binary search. In ASME 2013 International Design Engineering Technical Conferences and Computers and Information in Engineering Conference (pp. V03BT03A005-V03BT03A005). American Society of Mechanical Engineers.
pdf
- Burnap, A., Ren, Y., Papalambros, P. Y., Gonzalez, R., Gerth, R. (2013). A simulation based estimation of crowd ability and its influence on crowdsourced evaluation of design concepts. In ASME 2013 International Design Engineering Technical Conferences and Computers and Information in Engineering Conference (pp. V03BT03A004-V03BT03A004). American Society of Mechanical Engineers.
pdf
- Ren, Y., Burnap, A., Papalambros, P., others. (2013). Quantification of perceptual design attributes using a crowd. In Proceedings of the 19th International Conference on Engineering Design (ICED13) (Vol. 6).
pdf
- Bayrak, A. E., Ren, Y., Papalambros, P. Y. (2013). Design of Hybrid-Electric Vehicle Architectures Using Auto-Generation of Feasible Driving Modes. In ASME 2013 International Design Engineering Technical Conferences and Computers and Information in Engineering Conference (pp. V001T01A005-V001T01A005). American Society of Mechanical Engineers.
pdf
- Ren, Y., Papalambros, P. Y. (2012). On the Use of Active Learning in Engineering Design. In ASME 2012 International Design Engineering Technical Conferences and Computers and Information in Engineering Conference (pp. 89-98). American Society of Mechanical Engineers.
pdf
- Ren, Y., Papalambros, P. Y. (2012). On design preference elicitation with crowd implicit feedback. In ASME 2012 International Design Engineering Technical Conferences and Computers and Information in Engineering Conference. American Society of Mechanical Engineers.
pdf
- Ren, Y., Papalambros, P. Y. (2011). Design Preference Elicitation Using Efficient Global Optimization. In ASME 2011 International Design Engineering Technical Conferences and Computers and Information in Engineering Conference. American Society of Mechanical Engineers.
pdf
- Ren, Y., Papalambros, P. (2011). Design Preference Elicitation: Exploration and Learning. In Proceedings of the 18th International Conference on Engineering Design (ICED11) (Vol. 10, pp. 149-158).
pdf
- Ren, Y., Papalambros, P. Y. (2010). Design Preference Elicitation, Derivative-Free Optimization and Support Vector Machine Search. In ASME 2010 International Design Engineering Technical Conferences and Computers and Information in Engineering Conference. American Society of Mechanical Engineers.
pdf


- My education: I graduated from highschool in 2016, I studied pharmacy for 1 year at Hashemite University, then I converted to study physics at the University of Jordan, I graduated from college in 2020. I have attended 2 courses in programming, an ICDL course, and a Japanese language course.
- My job experience: I actually don't have that big work experience, I have worked in online teaching for a short time. I hope that I can find a decent job to work at.
My life goals
My goal in life is to be a better person that contibutes in making my community a better place to live in. I'm really trying to find the best way to achieve that, that's why I want to work in different fields and learn different things that might help me.


class NavigationProvider
Used to provide a list of NavigationSection and a menu to a NavigationActivity
See Also
NavigationProvider(: Array<out NavigationSection>, : Int)
Used to provide a list of NavigationSection and a menu to a NavigationActivity |
val mainMenu: Int |
|
val values: Array<out NavigationSection> |
fun <T> T.ifNull(block: () -> T?): T?
Execute the block only if null |


| Value | Network fees | Total value |
| {{model.value|money:'full'}} | {{model.fee|money:'full'}} | {{model.value + model.fee|money:'full'}} |
Your transaction has been prepared; the transaction need to be signed by
{{wallet.multisig.n}} wallet administrators (an email is sent to them).
| Value | Network fees | Total value |
| {{model.value|money:'full'}} | {{model.fee|money:'full'}} | {{model.value + model.fee|money:'full'}} |
| Value | Network fees | Total value |
| {{model.value|money:'full'}} | {{model.fee|money:'full'}} | {{model.value + model.fee|money:'full'}} |
Your transaction has been sent.
Your donation has been sent:
donation page


Welcome
02 Jan 2017Hello and Welcome to my website!
I'm Anvita, an undergraduate majoring in Computer Science (Biocomputation Track) at Stanford University.
To find out more about me, check out my About page.
For details on my projects, visit CS Research.
Or for more about my nonprofit, click here.
Connect with me:
*Due to the proprietary nature of many of my projects (e.g. drug discovery) most of my code is in private repos. If you have any specific questions/requests, however, feel free to send me an email


--- layout: archive title: Zulip Chat Archive permalink: /stream/113489-new-members/topic/simp.2C.20equality.2C.20and.20instances.html ---
Hi, I am trying to prove that list intersection with a singleton list is essentially a filter, and get this sub-goal:
lemma filter_mem_singleton_is_filter_eq {a} [decidable_eq a] {x : a} {xs : list a}: filter (λy, y ∈ [x]) xs = filter (λy, y = x) xs :=
this is more or less trivial, but for the implicite decidable
term in the filter. When I rewrite the mem term to be eq, the terms look like:
a : Type u_1, _inst_1 : decidable_eq a, x : a, xs : list a ⊢ @filter a (λ (y : a), y = x) (@eq.rec (a → Prop) (λ (y : a), y ∈ [x]) (@decidable_pred a) (λ (a_1 : a), @list.decidable_mem a _inst_1 a_1 [x]) (λ (y : a), y = x) _) xs = @filter a (λ (y : a), y = x) (λ (a : a), _inst_1 a x) xs
where the terms are equal but for the instance terms (after simp, dsimp
). I have run into this before, but managed to find a workaround. My questions is: is this common, and what is the solution, or am I doing something that is very un-lean?
When you get to that goal, use congr
to simplify it
before the rw
oh, nice, that works.
congr
knows about subsingleton arguments and will automatically prove they are equal. In this case decidable p
is a subsingleton
and a follow-on - is there somewhere I should be sending the lemmas I prove? They look like they should be in the standard library, but I don't know the protocol for submitting them. These are lemmas like the interaction between list.inter and const etc..
This should probably be going into mathlib. The core library is frozen and does not accept PRs
Although I'm not sure I want this particular theorem, it seems a bit specialized... Both sides are equivalent to list.repeat x (xs.count x)
This is a helper lemma, so maybe not. It looks like mathlib has a bunch of lemmas which may do what I want, anyway. Thanks!
{% endraw %}Last updated: Apr 24 2020 at 19:02 UTC


{include file="common\head"}
{include file="common\navbar"}
{include file="common\sidebar"} {__CONTENT__} {include file="common\footer"}
{include file="common\script"}


SNATCH A film review by Steve Rhodes Copyright 2001 Steve Rhodes RATING (0 TO ****): ** 1/2
Blood and guns. SNATCH is the second feature film by writer and director Guy Ritchie, who blasted onto the film scene a couple of years ago with his audacious LOCK, STOCK AND TWO SMOKING BARRELS. His latest movie is a hyper-violent, screwball comedy that doesn't pull any punches. And it's fun for a time until the repetition factor sets in. Coming from the more-is-always-better school of filmmaking, Ritchie tries to fill every fast-paced scene with maximum violence and mayhem.
SNATCH, which has more characters and overlapping stories that you can count, never has a slow moment. Most of the main stories revolve around an 86-caret diamond stolen by Franky Four Fingers (Benicio Del Toro) from Antwerp diamond dealers. After stealing it, he keeps the diamond in a briefcase, which is always attached by a chain to his arm. In the predictable script, you can probably guess exactly how he will be relieved of the stone.
The other major story involves an illegal, no-holds-barred boxing matching featuring an unintelligible gypsy named One Punch Mickey (Brad Pitt). One of many links between the two stories is an indestructible Russian gun dealer named Boris The Blade (Rade Serbedzija). Many of the characters, like Boris, can take more bullets than the agents in THE MATRIX and still keep on coming. The make-up department for SNATCH must have had to buy fake blood by the barrels.
Individual incidents are cute although few rise to the level of laugh-out-loud funny. Typical is the gag involving a trio of two-bit crooks, played by Robbie Gee, Lennie James and Ade. They have a pesky dog who swallows a toy, which causes him forever after to squeak rather than bark.
Rising to the top of the list of the characters who quickly get tiresome is Brick Top (Alan Ford), a nefarious boxing promoter who has man-eating pigs. Animal rights people may find many of the fighting animal scenes more than they can stomach even if the movie undoubtedly promises that no animals were harmed, etc.
As the ending credits roll, the song it plays has the constant refrain, "Ha, ha, ha, ha. Ha, ha, ha, ha." The movie is like that -- way too repetitive.
SNATCH runs 1:43. It is rated R for strong violence, language and some nudity and would be acceptable for high school seniors and older.
Email<EMAIL_ADDRESS>Web: http://www.InternetReviews.com
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


Overview
Package
Class
Use
Tree
Deprecated
Index
Help
PREV LETTER
NEXT LETTER
FRAMES
NO FRAMES
All Classes
A
B
C
D
E
F
G
H
I
L
M
N
O
P
R
S
T
U
V
W
T
TestObjReader
- Class in
ch.chnoch.thesis.renderer.util
The Class TestObjReader.
TestObjReader()
- Constructor for class ch.chnoch.thesis.renderer.util.
TestObjReader
Instantiates a new test obj reader.
Texture
- Interface in
ch.chnoch.thesis.renderer.interfaces
Declares the functionality to manage textures in OpenGL.
toString()
- Method in class ch.chnoch.thesis.renderer.
BoundingBox
toString()
- Method in class ch.chnoch.thesis.renderer.
Ray
toString()
- Method in class ch.chnoch.thesis.renderer.
RayShapeIntersection
TouchHandler
- Class in
ch.chnoch.thesis.renderer
This is a basic touch handler that is used for interacting with scenes that don't have support for a physics engine.
TouchHandler(SceneManagerInterface, RendererInterface, GLViewer, AbstractTouchHandler.CameraMode)
- Constructor for class ch.chnoch.thesis.renderer.
TouchHandler
Instantiates a new touch handler and sets up all the necessary objects.
Trackball
- Class in
ch.chnoch.thesis.renderer
A Trackball is used to intuitively rotate an arbitrary object in the world.
Trackball()
- Constructor for class ch.chnoch.thesis.renderer.
Trackball
Instantiates a new trackball.
transform(Matrix4f, Vector3f)
- Static method in class ch.chnoch.thesis.renderer.util.
Util
Transform.
TransformGroup
- Class in
ch.chnoch.thesis.renderer
A TransformGroup is a
Group
that has a transformation stored.
TransformGroup()
- Constructor for class ch.chnoch.thesis.renderer.
TransformGroup
Instantiates a new transform group.
Overview
Package
Class
Use
Tree
Deprecated
Index
Help
PREV LETTER
NEXT LETTER
FRAMES
NO FRAMES
All Classes
A
B
C
D
E
F
G
H
I
L
M
N
O
P
R
S
T
U
V
W


Methods summary
public
|
#
__construct( )
Constructor - $this->board = array(); $this->turn = Color::White;
$this->blackPieces = array(); $this->blackKing = null;
$this->whitePieces = array(); $this->whiteKing = null;
$this->turnCounter = 0; $this->history = new History();
|
public
|
|
public
|
#
DrawBoard( )
Method to draw the board with all pieces
Method to draw the board with all pieces
|
public
boolean
|
#
IsFinished( )
To know if the game is finished or not
To know if the game is finished or not
Returns
boolean True if the game is finished, false else
|
public
Piece
|
#
GetPiece( Position $position )
Get the piece at a specific position
Get the piece at a specific position
Parameters
- $position
Position
$position Position of the piece
Returns
Piece
Piece at the specific position
|
public
King
&
|
#
GetKing( Color $color )
Get a reference on the king of a specific player
Get a reference on the king of a specific player
Parameters
- $color
Color
$color Player color
Returns
King
King of the specific player
|
public
boolean
|
#
IsPromotion( Piece $piece, Position $target )
To know if the piece movement correspond to a promotion
To know if the piece movement correspond to a promotion
Parameters
- $piece
Piece
$piece Piece that may be promoted
- $target
Position
$target Piece's cell destination
Returns
boolean True if it's a promotion, false else
|
public
boolean
|
#
Move( Position $origin, Position $target )
Perform a move, from origin to target
Perform a move, from origin to target
Parameters
Returns
boolean True if no problem, false else
|
public
boolean
|
#
SimpleMove( Position $origin, Position $target, boolean $setPosition = true )
Perform a simple move of a piece, from a position to another position without
computing consequences, it's only used for the p revious link
Perform a simple move of a piece, from a position to another position without
computing consequences, it's only used for the p revious link
Parameters
- $origin
Position
$origin Origin position
- $target
Position
$target Target position
- $setPosition
boolean $setPosition Do we have to set the position inside the piece ?
Returns
boolean True, no problem, false else
|
public
Color
|
#
GetTurn( )
Return the color of the player whose turn it is
Return the color of the player whose turn it is
Returns
Color
Color of the player whose turn it is
|
public
integer
|
#
GetTurnCounter( )
To get the total number of turns
To get the total number of turns
Returns
integer Number of turn
|
public
string
|
#
DisplayTurn( )
Display the turn message
Returns
string Turn message
|
public
|
#
PreviousTurn( )
Perform some operations to back to the p revious turn
Perform some operations to back to the p revious turn
|
public
|
#
Previous( )
Perform the p revious move
Perform the p revious move
|
public
|
#
NextTurn( boolean $kingCheck = true )
Perform some operations to go to the next turn
Perform some operations to go to the next turn
Parameters
- $kingCheck
boolean $kingCheck True if we have to do king check verification, false else
|
public
|
|
public
Piece
|
#
AddPiece( string $type, Color $color, Position $position )
Add a piece to the game
Parameters
- $type
string $type Type of the piece
- $color
Color
$color Color of the piece
- $position
Position
$position Position of the piece
Returns
Piece
Return a reference of the piece added to the board
|
public
type
|
#
RemovePiece( Piece $target )
Totally remove a piece of the game
Totally remove a piece of the game
Parameters
- $target
Piece
$target The piece to remove
Returns
type True if the piece have been removed, false else
|
public
array
|
#
ComputeCollisionBoard( Color $color )
Compute the collision board of a specific player
Compute the collision board of a specific player
Parameters
- $color
Color
$color Color of the player
Returns
array The collision map
|
public
|
#
CleanPossibleCells( Color $color )
Clean the array of possible cells of every pieces with a particular color
Clean the array of possible cells of every pieces with a particular color
Parameters
- $color
Color
$color Color of the pieces
|
public
boolean
|
#
KingCheck( Color $color, boolean $logs = true )
Perform the king check verification
Perform the king check verification
Parameters
- $color
Color
$color Color of the player
- $logs
boolean $logs True if we want to write in the log output, false else
Returns
boolean True if the player of the specific color is in check
|
public
Piece
|
#
IsUnsecuredCell( Color $color, Position $position )
Check if a specific cell is secured or not
Check if a specific cell is secured or not
Parameters
- $color
Color
$color Color of the player
- $position
Position
$position Position of the cell which we want to know if it's secured or not
Returns
Piece
Return the piece that can attack this position
|
public
array
|
#
GetUnsecuredCells( Color $color )
Get the unsecured cells for a specific player
Get the unsecured cells for a specific player
Parameters
- $color
Color
$color Color of the player
Returns
array Return the unsecured cells
|
public
|
#
CleanUnsecuredCells( Piece $piece, array $unsecuredCells )
Remove unsecured cells from piece's possible cells
Remove unsecured cells from piece's possible cells
Parameters
- $piece
Piece
$piece The piece
- $unsecuredCells
array $unsecuredCells Array of unsecured cells
|
public
|
#
ComputeRealPossibleCells( Piece $piece )
Compute all possible cells of a piece including forbidden move because king
check
Compute all possible cells of a piece including forbidden move because king
check
Parameters
- $piece
Piece
$piece Piece whose we will compute the possible cells
|
public
array
|
#
ComputeTotalPossibleMoves( Color $color )
Compute all possible moves of a specific player
Compute all possible moves of a specific player
Parameters
- $color
Color
$color Color of the player
Returns
array Array of all possible moves of a specific player
|
public static
boolean
|
#
Out( Position $position )
To know if a position is out of the board
To know if a position is out of the board
Parameters
- $position
Position
$position The position to check
Returns
boolean True if the position is out of the board, false else
|


@steveklabnik
The Zen of Python: explicit is better than implicit
Ruby on Rails: Convention over configuration
GET /
Host: steveklabnik.com
$ curl -I steveklabnik.com
HTTP/1.1 200 OK
Content-Type: text/html
text/plain
text/html
application/json
image/png
Media types are explicit conventions.
Media types are explicit because we have Content-Type
and the related RFC.
Media types are conventions because we have a shared understanding of processing rules.
application/json
JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.
JSON's minimalism can only encode the vague structure of your data.
This has led to an explosion of bespoke, artisanal, hand-crafted APIs.
The purpose of the Content-Type field is to describe the data contained in the body fully enough that the receiving user agent can pick an appropriate agent or mechanism to present the data to the user, or otherwise deal with the data in an appropriate manner.
Any sufficiently advanced API contains an ad-hoc, informally specified implementation of some media type that extends JSON.
application/json
leads to bikeshedding. Bikeshedding leads to anger. Anger leads to hate. Hate leads to suffering.
JSON API assumes that you have some collection of data
that you'd like to synchronize across a network boundary.
Its conventions allow you to build
a smart client that minimizes requests.
It's based on real code used by real sites.
We use it at my employer to process payments.
If it's good enough for money, it's good enough for your API.
It's co-authored by Yehuda Katz and myself.
Here's what JSON API (in the ID style) looks like:
{
"posts": [{
"id": "1",
"title": "Rails is Omakase",
"links": {
"author": "9",
"comments": [ "5", "12", "17", "20" ]
}
}]
}
and in the URL style:
{
"posts": [{
"id": "1",
"title": "Rails is Omakase",
"links": {
"author": "http://example.com/people/1",
"comments": "http://example.com/comments/5,12,17,20"
}
}]
}
URI Templates:
{
"links": {
"posts.comments": "http://example.com/posts/{posts.id}/comments"
},
"posts": [{
"id": "1",
"title": "Rails is Omakase"
}, {
"id": "2",
"title": "The Parley Letter"
}]
}
Not just for GET
GET /photos
HTTP/1.1 200 OK
Content-Type: application/vnd.api+json
{
"photos": [{
"id": "1",
"title": "Mustaches on a Stick"
"src": "http://example.com/images/mustache.png"
}]
}
Not just for GET
POST /photos
Content-Type: application/vnd.api+json
Accept: application/vnd.api+json
{
"photos": [{
"title": "Ember Hamster",
"src": "http://example.com/images/productivity.png"
}]
}
Not just for GET
GET /photos
HTTP/1.1 200 OK
Content-Type: application/vnd.api+json
{
"photos": [{
"id": "1",
"title": "Mustaches on a Stick"
"src": "http://example.com/images/mustache.png"
}, {
"id": "2",
"title": "Ember Hamster",
"src": "http://example.com/images/productivity.png"
}]
}


AEC Library
Home
Courses
Youtube Channels
Question Banks
Study Materials
About
Courses
Informative Youtube Channels
Question Banks
Study Materials
View
View
View
View


PAYBACK Reviewed by Jamie Peck
In fact, it'd probably be a safe bet to accuse "Payback" of employing nary a nice guy in its complex story. Gibson's Porter character is the closest thing to a protagonist it has, and audiences will get the gist of his nastiness from the opening on: Not only does he narrate the film in the gravelly, low-octave hush commonly associated with the rogues gallery, we also get our first glimpse of him as he swipes a cash stash from a crippled vet. OK, so this panhandler turns out to be phony - even the bit parts aren't sympathetic here - but the point is that this Porter guy is someone with a vicious streak you definitely don't want to provoke.
Too late. Gibson starts off "Payback" already in a snit, and an understandable one at that. It seems he recently fell the victim of a scam at the hands of his duplicitous partner Val (Gregg Henry); Val helped Porter pull off a $140,000 heist from the Chinese mob and then stabbed - well, shot, if you really wanna know - his buddy in the back, leaving him for dead. But heavies rarely go down without a fight, and when Porter makes an unexpected recovery some months down the road, he hits the mean streets to track down Val and collect his $70,000 cut by any means necessary. This is where all the afore-mentioned unpleasantness kicks in.
"Payback" is so deliriously violent that audiences expecting a cuddly crime yarn a la the last few "Lethal Weapons" are going to be shocked into submission. And speaking of submission, one of the recurring vicious plot threads likely to distress unsuspecting viewers involves the kinky machinations of an Asian dominatrix named Pearl ("Ally McBeal"'s Lucy Liu), a gal who mingles pleasure and pain with malicious glee. Like it or not, the supporting cast includes many colorful roles like the above, and their featured sidetracks are far more fun to behold than Porter's pulpy lust for revenge. As assorted lowlifes, David Paymer, James Coburn, William Devane and Kris Kristofferson steal more than their share of scenes.
Much has been made of the fact that "Payback" had quite a troubled production schedule - apparently director Brian Helgeland's cut of the film did not appease Gibson, or something of the like, and a decent amount of new footage was reshot in order to lighten the tone a bit. It sort of shows: The first half of the movie is exceedingly dark and brooding in ways that are almost distancing, while act two exceedingly lets humor (mostly of the black comedy variety) and its star's never-fail charm seep into the mix. The hard-to-classify final result - you try putting it in the appropriate genre - is dangerously uneven but still a decent game of double-crossing and one-upmanship.
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


| Name | Chksum | Status | View Results | Report | Delete |
|---|---|---|---|---|---|
| {{datafile.name}} | {{ datafile.chksum}} | {{ datafile.status }} |
Processing ..
Uploaded
|
Processing ..
Uploaded
|


@* * Copyright 2023 HM Revenue & Customs * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. *@ @import uk.gov.hmrc.govukfrontend.views.html.components._ @import views.html.components.gds._ @import views.Title @this( mainTemplate: gdsMainTemplate, errorSummary: errorSummary, formHelper: FormWithCSRF, exportsInputText: exportsInputText, paragraphBody: paragraphBody, govukInsetText: GovukInsetText, bulletList: bulletList, govukButton: GovukButton, pageTitle: pageTitle ) @(form: Form[FileUploadCount], mrn: MRN)(implicit request: Request[_], messages: Messages) @mainTemplate(title = Title("howManyFilesUpload.heading"), backLinkUrl = Some(routes.ContactDetailsController.onPageLoad.url)) {


#include <config.h>
Definition at line 16 of file config.h.
| int Config::dectoa |
( |
char ** |
p | ) |
|
|
private |
| char Config::dtoa |
( |
char |
c | ) |
|
|
private |
| int Config::get_param |
( |
char * |
buff, |
|
|
char ** |
param_name, |
|
|
char ** |
param_value, |
|
|
int |
line_nbr |
|
) |
| |
| char Config::hextoa |
( |
char ** |
p | ) |
|
|
private |
| char Config::octtoa |
( |
char ** |
p | ) |
|
|
private |
| char Config::otoa |
( |
char |
c | ) |
|
|
private |
| void Config::showState |
( |
| ) |
|
| char Config::xtoa |
( |
char |
c | ) |
|
|
private |
Initial value:This is the configuration parameters structure that contains the information for all accpetable config elements of PIano. The initialization of this structure is done statically inside main.cpp source file.
Definition at line 22 of file config.h.
The documentation for this class was generated from the following files:


White to play 22
pips White=98 Black=129
(CorrectAnswer= 0/0, ErrorScore= 0)
1. 16/12 3/1(2) eq: +0.316 58.76% (G:17.08% B:0.19%) 41.24% (G:10.11% B:0.26%) 2. 11/7(2) eq: +0.305 (-0.011) 56.97% (G:19.99% B:0.42%) 43.03% (G:14.06% B:0.55%) 3. 16/14 11/9(2) 3/1 eq: +0.291 (-0.025) 55.85% (G:17.13% B:0.23%) 44.15% (G:15.09% B:0.66%) 4. 16/14 11/9(2) 4/2 eq: +0.260 (-0.056) 55.63% (G:18.43% B:0.41%) 44.37% (G:15.39% B:0.60%) 5. 16/12 11/9(2) eq: +0.252 (-0.064) 54.96% (G:18.45% B:0.47%) 45.04% (G:15.41% B:0.65%)


PERLTOOC
Section: Perl Programmers Reference Guide (1)Updated: 2009-02-12
Index Return to Main Contents
NAME
perltooc - Tom's OO Tutorial for Class Data in PerlDESCRIPTION
When designing an object class, you are sometimes faced with the situation of wanting common state shared by all objects of that class. Such class attributes act somewhat like global variables for the entire class, but unlike program-wide globals, class attributes have meaning only to the class itself.Here are a few examples where class attributes might come in handy:
- *
- to keep a count of the objects you've created, or how many are still extant.
- *
- to extract the name or file descriptor for a logfile used by a debugging method.
- *
- to access collective data, like the total amount of cash dispensed by all ATMs in a network in a given day.
- *
- to access the last object created by a class, or the most accessed object, or to retrieve a list of all objects.
Unlike a true global, class attributes should not be accessed directly. Instead, their state should be inspected, and perhaps altered, only through the mediated access of class methods. These class attributes accessor methods are similar in spirit and function to accessors used to manipulate the state of instance attributes on an object. They provide a clear firewall between interface and implementation.
You should allow access to class attributes through either the class name or any object of that class. If we assume that $an_object is of type Some_Class, and the &Some_Class::population_count method accesses class attributes, then these two invocations should both be possible, and almost certainly equivalent.
Some_Class->population_count() $an_object->population_count()
The question is, where do you store the state which that method accesses? Unlike more restrictive languages like C++, where these are called static data members, Perl provides no syntactic mechanism to declare class attributes, any more than it provides a syntactic mechanism to declare instance attributes. Perl provides the developer with a broad set of powerful but flexible features that can be uniquely crafted to the particular demands of the situation.
A class in Perl is typically implemented in a module. A module consists of two complementary feature sets: a package for interfacing with the outside world, and a lexical file scope for privacy. Either of these two mechanisms can be used to implement class attributes. That means you get to decide whether to put your class attributes in package variables or to put them in lexical variables.
And those aren't the only decisions to make. If you choose to use package variables, you can make your class attribute accessor methods either ignorant of inheritance or sensitive to it. If you choose lexical variables, you can elect to permit access to them from anywhere in the entire file scope, or you can limit direct data access exclusively to the methods implementing those attributes.
Class Data in a Can
One of the easiest ways to solve a hard problem is to let someone else do it for you! In this case, Class::Data::Inheritable (available on a CPAN near you) offers a canned solution to the class data problem using closures. So before you wade into this document, consider having a look at that module.Class Data as Package Variables
Because a class in Perl is really just a package, using package variables to hold class attributes is the most natural choice. This makes it simple for each class to have its own class attributes. Let's say you have a class called Some_Class that needs a couple of different attributes that you'd like to be global to the entire class. The simplest thing to do is to use package variables like $Some_Class::CData1 and $Some_Class::CData2 to hold these attributes. But we certainly don't want to encourage outsiders to touch those data directly, so we provide methods to mediate access.In the accessor methods below, we'll for now just ignore the first argument---that part to the left of the arrow on method invocation, which is either a class name or an object reference.
package Some_Class; sub CData1 { shift; # XXX: ignore calling class/object $Some_Class::CData1 = shift if @_; return $Some_Class::CData1; } sub CData2 { shift; # XXX: ignore calling class/object $Some_Class::CData2 = shift if @_; return $Some_Class::CData2; }
This technique is highly legible and should be completely straightforward to even the novice Perl programmer. By fully qualifying the package variables, they stand out clearly when reading the code. Unfortunately, if you misspell one of these, you've introduced an error that's hard to catch. It's also somewhat disconcerting to see the class name itself hard-coded in so many places.
Both these problems can be easily fixed. Just add the "use strict" pragma, then pre-declare your package variables. (The "our" operator will be new in 5.6, and will work for package globals just like "my" works for scoped lexicals.)
package Some_Class; use strict; our($CData1, $CData2); # our() is new to perl5.6 sub CData1 { shift; # XXX: ignore calling class/object $CData1 = shift if @_; return $CData1; } sub CData2 { shift; # XXX: ignore calling class/object $CData2 = shift if @_; return $CData2; }
As with any other global variable, some programmers prefer to start their package variables with capital letters. This helps clarity somewhat, but by no longer fully qualifying the package variables, their significance can be lost when reading the code. You can fix this easily enough by choosing better names than were used here.
Putting All Your Eggs in One Basket
Just as the mindless enumeration of accessor methods for instance attributes grows tedious after the first few (see perltoot), so too does the repetition begin to grate when listing out accessor methods for class data. Repetition runs counter to the primary virtue of a programmer: Laziness, here manifesting as that innate urge every programmer feels to factor out duplicate code whenever possible.Here's what to do. First, make just one hash to hold all class attributes.
package Some_Class; use strict; our %ClassData = ( # our() is new to perl5.6 CData1 => "", CData2 => "", );
Using closures (see perlref) and direct access to the package symbol table (see perlmod), now clone an accessor method for each key in the %ClassData hash. Each of these methods is used to fetch or store values to the specific, named class attribute.
for my $datum (keys %ClassData) { no strict "refs"; # to register new methods in package *$datum = sub { shift; # XXX: ignore calling class/object $ClassData{$datum} = shift if @_; return $ClassData{$datum}; } }
It's true that you could work out a solution employing an &AUTOLOAD method, but this approach is unlikely to prove satisfactory. Your function would have to distinguish between class attributes and object attributes; it could interfere with inheritance; and it would have to careful about DESTROY. Such complexity is uncalled for in most cases, and certainly in this one.
You may wonder why we're rescinding strict refs for the loop. We're manipulating the package's symbol table to introduce new function names using symbolic references (indirect naming), which the strict pragma would otherwise forbid. Normally, symbolic references are a dodgy notion at best. This isn't just because they can be used accidentally when you aren't meaning to. It's also because for most uses to which beginning Perl programmers attempt to put symbolic references, we have much better approaches, like nested hashes or hashes of arrays. But there's nothing wrong with using symbolic references to manipulate something that is meaningful only from the perspective of the package symbol table, like method names or package variables. In other words, when you want to refer to the symbol table, use symbol references.
Clustering all the class attributes in one place has several advantages. They're easy to spot, initialize, and change. The aggregation also makes them convenient to access externally, such as from a debugger or a persistence package. The only possible problem is that we don't automatically know the name of each class's class object, should it have one. This issue is addressed below in ``The Eponymous Meta-Object''.
Inheritance Concerns
Suppose you have an instance of a derived class, and you access class data using an inherited method call. Should that end up referring to the base class's attributes, or to those in the derived class? How would it work in the earlier examples? The derived class inherits all the base class's methods, including those that access class attributes. But what package are the class attributes stored in?The answer is that, as written, class attributes are stored in the package into which those methods were compiled. When you invoke the &CData1 method on the name of the derived class or on one of that class's objects, the version shown above is still run, so you'll access $Some_Class::CData1--or in the method cloning version, $Some_Class::ClassData{CData1}.
Think of these class methods as executing in the context of their base class, not in that of their derived class. Sometimes this is exactly what you want. If Feline subclasses Carnivore, then the population of Carnivores in the world should go up when a new Feline is born. But what if you wanted to figure out how many Felines you have apart from Carnivores? The current approach doesn't support that.
You'll have to decide on a case-by-case basis whether it makes any sense for class attributes to be package-relative. If you want it to be so, then stop ignoring the first argument to the function. Either it will be a package name if the method was invoked directly on a class name, or else it will be an object reference if the method was invoked on an object reference. In the latter case, the ref() function provides the class of that object.
package Some_Class; sub CData1 { my $obclass = shift; my $class = ref($obclass) || $obclass; my $varname = $class . "::CData1"; no strict "refs"; # to access package data symbolically $$varname = shift if @_; return $$varname; }
And then do likewise for all other class attributes (such as CData2, etc.) that you wish to access as package variables in the invoking package instead of the compiling package as we had previously.
Once again we temporarily disable the strict references ban, because otherwise we couldn't use the fully-qualified symbolic name for the package global. This is perfectly reasonable: since all package variables by definition live in a package, there's nothing wrong with accessing them via that package's symbol table. That's what it's there for (well, somewhat).
What about just using a single hash for everything and then cloning methods? What would that look like? The only difference would be the closure used to produce new method entries for the class's symbol table.
no strict "refs"; *$datum = sub { my $obclass = shift; my $class = ref($obclass) || $obclass; my $varname = $class . "::ClassData"; $varname->{$datum} = shift if @_; return $varname->{$datum}; }
The Eponymous Meta-Object
It could be argued that the %ClassData hash in the previous example is neither the most imaginative nor the most intuitive of names. Is there something else that might make more sense, be more useful, or both?As it happens, yes, there is. For the ``class meta-object'', we'll use a package variable of the same name as the package itself. Within the scope of a package Some_Class declaration, we'll use the eponymously named hash %Some_Class as that class's meta-object. (Using an eponymously named hash is somewhat reminiscent of classes that name their constructors eponymously in the Python or C++ fashion. That is, class Some_Class would use &Some_Class::Some_Class as a constructor, probably even exporting that name as well. The StrNum class in Recipe 13.14 in The Perl Cookbook does this, if you're looking for an example.)
This predictable approach has many benefits, including having a well-known identifier to aid in debugging, transparent persistence, or checkpointing. It's also the obvious name for monadic classes and translucent attributes, discussed later.
Here's an example of such a class. Notice how the name of the hash storing the meta-object is the same as the name of the package used to implement the class.
package Some_Class; use strict; # create class meta-object using that most perfect of names our %Some_Class = ( # our() is new to perl5.6 CData1 => "", CData2 => "", ); # this accessor is calling-package-relative sub CData1 { my $obclass = shift; my $class = ref($obclass) || $obclass; no strict "refs"; # to access eponymous meta-object $class->{CData1} = shift if @_; return $class->{CData1}; } # but this accessor is not sub CData2 { shift; # XXX: ignore calling class/object no strict "refs"; # to access eponymous meta-object __PACKAGE__ -> {CData2} = shift if @_; return __PACKAGE__ -> {CData2}; }
In the second accessor method, the __PACKAGE__ notation was used for two reasons. First, to avoid hardcoding the literal package name in the code in case we later want to change that name. Second, to clarify to the reader that what matters here is the package currently being compiled into, not the package of the invoking object or class. If the long sequence of non-alphabetic characters bothers you, you can always put the __PACKAGE__ in a variable first.
sub CData2 { shift; # XXX: ignore calling class/object no strict "refs"; # to access eponymous meta-object my $class = __PACKAGE__; $class->{CData2} = shift if @_; return $class->{CData2}; }
Even though we're using symbolic references for good not evil, some folks tend to become unnerved when they see so many places with strict ref checking disabled. Given a symbolic reference, you can always produce a real reference (the reverse is not true, though). So we'll create a subroutine that does this conversion for us. If invoked as a function of no arguments, it returns a reference to the compiling class's eponymous hash. Invoked as a class method, it returns a reference to the eponymous hash of its caller. And when invoked as an object method, this function returns a reference to the eponymous hash for whatever class the object belongs to.
package Some_Class; use strict; our %Some_Class = ( # our() is new to perl5.6 CData1 => "", CData2 => "", ); # tri-natured: function, class method, or object method sub _classobj { my $obclass = shift || __PACKAGE__; my $class = ref($obclass) || $obclass; no strict "refs"; # to convert sym ref to real one return \%$class; } for my $datum (keys %{ _classobj() } ) { # turn off strict refs so that we can # register a method in the symbol table no strict "refs"; *$datum = sub { use strict "refs"; my $self = shift->_classobj(); $self->{$datum} = shift if @_; return $self->{$datum}; } }
Indirect References to Class Data
A reasonably common strategy for handling class attributes is to store a reference to each package variable on the object itself. This is a strategy you've probably seen before, such as in perltoot and perlbot, but there may be variations in the example below that you haven't thought of before.
package Some_Class; our($CData1, $CData2); # our() is new to perl5.6 sub new { my $obclass = shift; return bless my $self = { ObData1 => "", ObData2 => "", CData1 => \$CData1, CData2 => \$CData2, } => (ref $obclass || $obclass); } sub ObData1 { my $self = shift; $self->{ObData1} = shift if @_; return $self->{ObData1}; } sub ObData2 { my $self = shift; $self->{ObData2} = shift if @_; return $self->{ObData2}; } sub CData1 { my $self = shift; my $dataref = ref $self ? $self->{CData1} : \$CData1; $$dataref = shift if @_; return $$dataref; } sub CData2 { my $self = shift; my $dataref = ref $self ? $self->{CData2} : \$CData2; $$dataref = shift if @_; return $$dataref; }
As written above, a derived class will inherit these methods, which will consequently access package variables in the base class's package. This is not necessarily expected behavior in all circumstances. Here's an example that uses a variable meta-object, taking care to access the proper package's data.
package Some_Class; use strict; our %Some_Class = ( # our() is new to perl5.6 CData1 => "", CData2 => "", ); sub _classobj { my $self = shift; my $class = ref($self) || $self; no strict "refs"; # get (hard) ref to eponymous meta-object return \%$class; } sub new { my $obclass = shift; my $classobj = $obclass->_classobj(); bless my $self = { ObData1 => "", ObData2 => "", CData1 => \$classobj->{CData1}, CData2 => \$classobj->{CData2}, } => (ref $obclass || $obclass); return $self; } sub ObData1 { my $self = shift; $self->{ObData1} = shift if @_; return $self->{ObData1}; } sub ObData2 { my $self = shift; $self->{ObData2} = shift if @_; return $self->{ObData2}; } sub CData1 { my $self = shift; $self = $self->_classobj() unless ref $self; my $dataref = $self->{CData1}; $$dataref = shift if @_; return $$dataref; } sub CData2 { my $self = shift; $self = $self->_classobj() unless ref $self; my $dataref = $self->{CData2}; $$dataref = shift if @_; return $$dataref; }
Not only are we now strict refs clean, using an eponymous meta-object seems to make the code cleaner. Unlike the previous version, this one does something interesting in the face of inheritance: it accesses the class meta-object in the invoking class instead of the one into which the method was initially compiled.
You can easily access data in the class meta-object, making it easy to dump the complete class state using an external mechanism such as when debugging or implementing a persistent class. This works because the class meta-object is a package variable, has a well-known name, and clusters all its data together. (Transparent persistence is not always feasible, but it's certainly an appealing idea.)
There's still no check that object accessor methods have not been invoked on a class name.  If not, then you get the eponymous meta-object. What you do with---or about---this is up to you. The next two sections demonstrate innovative uses for this powerful feature.
Monadic Classes
Some of the standard modules shipped with Perl provide class interfaces without any attribute methods whatsoever. The most commonly used module not numbered amongst the pragmata, the Exporter module, is a class with neither constructors nor attributes. Its job is simply to provide a standard interface for modules wishing to export part of their namespace into that of their caller. Modules use the Exporter's &import method by setting their inheritance list in their package's @ISA array to mention ``Exporter''. But class Exporter provides no constructor, so you can't have several instances of the class. In fact, you can't have any---it just doesn't make any sense. All you get is its methods. Its interface contains no statefulness, so state data is wholly superfluous.Another sort of class that pops up from time to time is one that supports a unique instance. Such classes are called monadic classes, or less formally, singletons or highlander classes.
If a class is monadic, where do you store its state, that is, its attributes? How do you make sure that there's never more than one instance? While you could merely use a slew of package variables, it's a lot cleaner to use the eponymously named hash. Here's a complete example of a monadic class:
package Cosmos; %Cosmos = (); # accessor method for "name" attribute sub name { my $self = shift; $self->{name} = shift if @_; return $self->{name}; } # read-only accessor method for "birthday" attribute sub birthday { my $self = shift; die "can't reset birthday" if @_; # XXX: croak() is better return $self->{birthday}; } # accessor method for "stars" attribute sub stars { my $self = shift; $self->{stars} = shift if @_; return $self->{stars}; } # oh my - one of our stars just went out! sub supernova { my $self = shift; my $count = $self->stars(); $self->stars($count - 1) if $count > 0; } # constructor/initializer method - fix by reboot sub bigbang { my $self = shift; %$self = ( name => "the world according to tchrist", birthday => time(), stars => 0, ); return $self; # yes, it's probably a class. SURPRISE! } # After the class is compiled, but before any use or require # returns, we start off the universe with a bang. __PACKAGE__ -> bigbang();
Hold on, that doesn't look like anything special. Those attribute accessors look no different than they would if this were a regular class instead of a monadic one. The crux of the matter is there's nothing that says that $self must hold a reference to a blessed object. It merely has to be something you can invoke methods on. Here the package name itself, Cosmos, works as an object. Look at the &supernova method. Is that a class method or an object method? The answer is that static analysis cannot reveal the answer. Perl doesn't care, and neither should you. In the three attribute methods, %$self is really accessing the %Cosmos package variable.
If like Stephen Hawking, you posit the existence of multiple, sequential, and unrelated universes, then you can invoke the &bigbang method yourself at any time to start everything all over again. You might think of &bigbang as more of an initializer than a constructor, since the function doesn't allocate new memory; it only initializes what's already there. But like any other constructor, it does return a scalar value to use for later method invocations.
Imagine that some day in the future, you decide that one universe just isn't enough. You could write a new class from scratch, but you already have an existing class that does what you want---except that it's monadic, and you want more than just one cosmos.
That's what code reuse via subclassing is all about. Look how short the new code is:
package Multiverse; use Cosmos; @ISA = qw(Cosmos); sub new { my $protoverse = shift; my $class = ref($protoverse) || $protoverse; my $self = {}; return bless($self, $class)->bigbang(); } 1;
Because we were careful to be good little creators when we designed our Cosmos class, we can now reuse it without touching a single line of code when it comes time to write our Multiverse class. The same code that worked when invoked as a class method continues to work perfectly well when invoked against separate instances of a derived class.
The astonishing thing about the Cosmos class above is that the value returned by the &bigbang ``constructor'' is not a reference to a blessed object at all. It's just the class's own name. A class name is, for virtually all intents and purposes, a perfectly acceptable object. It has state, behavior, and identity, the three crucial components of an object system. It even manifests inheritance, polymorphism, and encapsulation. And what more can you ask of an object?
To understand object orientation in Perl, it's important to recognize the unification of what other programming languages might think of as class methods and object methods into just plain methods. ``Class methods'' and ``object methods'' are distinct only in the compartmentalizing mind of the Perl programmer, not in the Perl language itself.
Along those same lines, a constructor is nothing special either, which is one reason why Perl has no pre-ordained name for them. ``Constructor'' is just an informal term loosely used to describe a method that returns a scalar value that you can make further method calls against. So long as it's either a class name or an object reference, that's good enough. It doesn't even have to be a reference to a brand new object.
You can have as many---or as few---constructors as you want, and you can name them whatever you care to. Blindly and obediently using new() for each and every constructor you ever write is to speak Perl with such a severe C++ accent that you do a disservice to both languages. There's no reason to insist that each class have but one constructor, or that a constructor be named new(), or that a constructor be used solely as a class method and not an object method.
The next section shows how useful it can be to further distance ourselves from any formal distinction between class method calls and object method calls, both in constructors and in accessor methods.
Translucent Attributes
A package's eponymous hash can be used for more than just containing per-class, global state data. It can also serve as a sort of template containing default settings for object attributes. These default settings can then be used in constructors for initialization of a particular object. The class's eponymous hash can also be used to implement translucent attributes. A translucent attribute is one that has a class-wide default. Each object can set its own value for the attribute, in which case "$object->attribute()" returns that value. But if no value has been set, then "$object->attribute()" returns the class-wide default.We'll apply something of a copy-on-write approach to these translucent attributes. If you're just fetching values from them, you get translucency. But if you store a new value to them, that new value is set on the current object. On the other hand, if you use the class as an object and store the attribute value directly on the class, then the meta-object's value changes, and later fetch operations on objects with uninitialized values for those attributes will retrieve the meta-object's new values. Objects with their own initialized values, however, won't see any change.
Let's look at some concrete examples of using these properties before we show how to implement them. Suppose that a class named Some_Class had a translucent data attribute called ``color''. First you set the color in the meta-object, then you create three objects using a constructor that happens to be named &spawn.
use Vermin; Vermin->color("vermilion"); $ob1 = Vermin->spawn(); # so that's where Jedi come from $ob2 = Vermin->spawn(); $ob3 = Vermin->spawn(); print $obj3->color(); # prints "vermilion"
Each of these objects' colors is now ``vermilion'', because that's the meta-object's value for that attribute, and these objects do not have individual color values set.
Changing the attribute on one object has no effect on other objects previously created.
$ob3->color("chartreuse"); print $ob3->color(); # prints "chartreuse" print $ob1->color(); # prints "vermilion", translucently
If you now use $ob3 to spawn off another object, the new object will take the color its parent held, which now happens to be ``chartreuse''. That's because the constructor uses the invoking object as its template for initializing attributes. When that invoking object is the class name, the object used as a template is the eponymous meta-object. When the invoking object is a reference to an instantiated object, the &spawn constructor uses that existing object as a template.
$ob4 = $ob3->spawn(); # $ob3 now template, not %Vermin print $ob4->color(); # prints "chartreuse"
Any actual values set on the template object will be copied to the new object. But attributes undefined in the template object, being translucent, will remain undefined and consequently translucent in the new one as well.
Now let's change the color attribute on the entire class:
Vermin->color("azure"); print $ob1->color(); # prints "azure" print $ob2->color(); # prints "azure" print $ob3->color(); # prints "chartreuse" print $ob4->color(); # prints "chartreuse"
That color change took effect only in the first pair of objects, which were still translucently accessing the meta-object's values. The second pair had per-object initialized colors, and so didn't change.
One important question remains. Changes to the meta-object are reflected in translucent attributes in the entire class, but what about changes to discrete objects? If you change the color of $ob3, does the value of $ob4 see that change? Or vice-versa. If you change the color of $ob4, does then the value of $ob3 shift?
$ob3->color("amethyst"); print $ob3->color(); # prints "amethyst" print $ob4->color(); # hmm: "chartreuse" or "amethyst"?
While one could argue that in certain rare cases it should, let's not do that. Good taste aside, we want the answer to the question posed in the comment above to be ``chartreuse'', not ``amethyst''. So we'll treat these attributes similar to the way process attributes like environment variables, user and group IDs, or the current working directory are treated across a fork(). You can change only yourself, but you will see those changes reflected in your unspawned children. Changes to one object will propagate neither up to the parent nor down to any existing child objects. Those objects made later, however, will see the changes.
If you have an object with an actual attribute value, and you want to make that object's attribute value translucent again, what do you do? Let's design the class so that when you invoke an accessor method with "undef" as its argument, that attribute returns to translucency.
$ob4->color(undef); # back to "azure"
Here's a complete implementation of Vermin as described above.
package Vermin; # here's the class meta-object, eponymously named. # it holds all class attributes, and also all instance attributes # so the latter can be used for both initialization # and translucency. our %Vermin = ( # our() is new to perl5.6 PopCount => 0, # capital for class attributes color => "beige", # small for instance attributes ); # constructor method # invoked as class method or object method sub spawn { my $obclass = shift; my $class = ref($obclass) || $obclass; my $self = {}; bless($self, $class); $class->{PopCount}++; # init fields from invoking object, or omit if # invoking object is the class to provide translucency %$self = %$obclass if ref $obclass; return $self; } # translucent accessor for "color" attribute # invoked as class method or object method sub color { my $self = shift; my $class = ref($self) || $self; # handle class invocation unless (ref $self) { $class->{color} = shift if @_; return $class->{color} } # handle object invocation $self->{color} = shift if @_; if (defined $self->{color}) { # not exists! return $self->{color}; } else { return $class->{color}; } } # accessor for "PopCount" class attribute # invoked as class method or object method # but uses object solely to locate meta-object sub population { my $obclass = shift; my $class = ref($obclass) || $obclass; return $class->{PopCount}; } # instance destructor # invoked only as object method sub DESTROY { my $self = shift; my $class = ref $self; $class->{PopCount}--; }
Here are a couple of helper methods that might be convenient. They aren't accessor methods at all. They're used to detect accessibility of data attributes. The &is_translucent method determines whether a particular object attribute is coming from the meta-object. The &has_attribute method detects whether a class implements a particular property at all. It could also be used to distinguish undefined properties from non-existent ones.
# detect whether an object attribute is translucent # (typically?) invoked only as object method sub is_translucent { my($self, $attr) = @_; return !defined $self->{$attr}; } # test for presence of attribute in class # invoked as class method or object method sub has_attribute { my($self, $attr) = @_; my $class = ref($self) || $self; return exists $class->{$attr}; }
If you prefer to install your accessors more generically, you can make use of the upper-case versus lower-case convention to register into the package appropriate methods cloned from generic closures.
for my $datum (keys %{ +__PACKAGE__ }) { *$datum = ($datum =~ /^[A-Z]/) ? sub { # install class accessor my $obclass = shift; my $class = ref($obclass) || $obclass; return $class->{$datum}; } : sub { # install translucent accessor my $self = shift; my $class = ref($self) || $self; unless (ref $self) { $class->{$datum} = shift if @_; return $class->{$datum} } $self->{$datum} = shift if @_; return defined $self->{$datum} ? $self -> {$datum} : $class -> {$datum} } }
Translations of this closure-based approach into C++, Java, and Python have been left as exercises for the reader. Be sure to send us mail as soon as you're done.
Class Data as Lexical Variables
Privacy and Responsibility
Unlike conventions used by some Perl programmers, in the previous examples, we didn't prefix the package variables used for class attributes with an underscore, nor did we do so for the names of the hash keys used for instance attributes. You don't need little markers on data names to suggest nominal privacy on attribute variables or hash keys, because these are already notionally private! Outsiders have no business whatsoever playing with anything within a class save through the mediated access of its documented interface; in other words, through method invocations. And not even through just any method, either. Methods that begin with an underscore are traditionally considered off-limits outside the class. If outsiders skip the documented method interface to poke around the internals of your class and end up breaking something, that's not your fault---it's theirs.Perl believes in individual responsibility rather than mandated control. Perl respects you enough to let you choose your own preferred level of pain, or of pleasure. Perl believes that you are creative, intelligent, and capable of making your own decisions---and fully expects you to take complete responsibility for your own actions. In a perfect world, these admonitions alone would suffice, and everyone would be intelligent, responsible, happy, and creative. And careful. One probably shouldn't forget careful, and that's a good bit harder to expect. Even Einstein would take wrong turns by accident and end up lost in the wrong part of town.
Some folks get the heebie-jeebies when they see package variables hanging out there for anyone to reach over and alter them. Some folks live in constant fear that someone somewhere might do something wicked. The solution to that problem is simply to fire the wicked, of course. But unfortunately, it's not as simple as all that. These cautious types are also afraid that they or others will do something not so much wicked as careless, whether by accident or out of desperation. If we fire everyone who ever gets careless, pretty soon there won't be anybody left to get any work done.
Whether it's needless paranoia or sensible caution, this uneasiness can be a problem for some people. We can take the edge off their discomfort by providing the option of storing class attributes as lexical variables instead of as package variables. The my() operator is the source of all privacy in Perl, and it is a powerful form of privacy indeed.
It is widely perceived, and indeed has often been written, that Perl provides no data hiding, that it affords the class designer no privacy nor isolation, merely a rag-tag assortment of weak and unenforceable social conventions instead. This perception is demonstrably false and easily disproven. In the next section, we show how to implement forms of privacy that are far stronger than those provided in nearly any other object-oriented language.
File-Scoped Lexicals
A lexical variable is visible only through the end of its static scope. That means that the only code able to access that variable is code residing textually below the my() operator through the end of its block if it has one, or through the end of the current file if it doesn't.Starting again with our simplest example given at the start of this document, we replace our() variables with my() versions.
package Some_Class; my($CData1, $CData2); # file scope, not in any package sub CData1 { shift; # XXX: ignore calling class/object $CData1 = shift if @_; return $CData1; } sub CData2 { shift; # XXX: ignore calling class/object $CData2 = shift if @_; return $CData2; }
So much for that old $Some_Class::CData1 package variable and its brethren! Those are gone now, replaced with lexicals. No one outside the scope can reach in and alter the class state without resorting to the documented interface. Not even subclasses or superclasses of this one have unmediated access to $CData1. They have to invoke the &CData1 method against Some_Class or an instance thereof, just like anybody else.
To be scrupulously honest, that last statement assumes you haven't packed several classes together into the same file scope, nor strewn your class implementation across several different files. Accessibility of those variables is based uniquely on the static file scope. It has nothing to do with the package. That means that code in a different file but the same package (class) could not access those variables, yet code in the same file but a different package (class) could. There are sound reasons why we usually suggest a one-to-one mapping between files and packages and modules and classes. You don't have to stick to this suggestion if you really know what you're doing, but you're apt to confuse yourself otherwise, especially at first.
If you'd like to aggregate your class attributes into one lexically scoped, composite structure, you're perfectly free to do so.
package Some_Class; my %ClassData = ( CData1 => "", CData2 => "", ); sub CData1 { shift; # XXX: ignore calling class/object $ClassData{CData1} = shift if @_; return $ClassData{CData1}; } sub CData2 { shift; # XXX: ignore calling class/object $ClassData{CData2} = shift if @_; return $ClassData{CData2}; }
To make this more scalable as other class attributes are added, we can again register closures into the package symbol table to create accessor methods for them.
package Some_Class; my %ClassData = ( CData1 => "", CData2 => "", ); for my $datum (keys %ClassData) { no strict "refs"; *$datum = sub { shift; # XXX: ignore calling class/object $ClassData{$datum} = shift if @_; return $ClassData{$datum}; }; }
Requiring even your own class to use accessor methods like anybody else is probably a good thing. But demanding and expecting that everyone else, be they subclass or superclass, friend or foe, will all come to your object through mediation is more than just a good idea. It's absolutely critical to the model. Let there be in your mind no such thing as ``public'' data, nor even ``protected'' data, which is a seductive but ultimately destructive notion. Both will come back to bite at you. That's because as soon as you take that first step out of the solid position in which all state is considered completely private, save from the perspective of its own accessor methods, you have violated the envelope. And, having pierced that encapsulating envelope, you shall doubtless someday pay the price when future changes in the implementation break unrelated code. Considering that avoiding this infelicitous outcome was precisely why you consented to suffer the slings and arrows of obsequious abstraction by turning to object orientation in the first place, such breakage seems unfortunate in the extreme.
More Inheritance Concerns
Suppose that Some_Class were used as a base class from which to derive Another_Class. If you invoke a &CData method on the derived class or on an object of that class, what do you get? Would the derived class have its own state, or would it piggyback on its base class's versions of the class attributes?The answer is that under the scheme outlined above, the derived class would not have its own state data. As before, whether you consider this a good thing or a bad one depends on the semantics of the classes involved.
The cleanest, sanest, simplest way to address per-class state in a lexical is for the derived class to override its base class's version of the method that accesses the class attributes. Since the actual method called is the one in the object's derived class if this exists, you automatically get per-class state this way. Any urge to provide an unadvertised method to sneak out a reference to the %ClassData hash should be strenuously resisted.
As with any other overridden method, the implementation in the derived class always has the option of invoking its base class's version of the method in addition to its own. Here's an example:
package Another_Class; @ISA = qw(Some_Class); my %ClassData = ( CData1 => "", ); sub CData1 { my($self, $newvalue) = @_; if (@_ > 1) { # set locally first $ClassData{CData1} = $newvalue; # then pass the buck up to the first # overridden version, if there is one if ($self->can("SUPER::CData1")) { $self->SUPER::CData1($newvalue); } } return $ClassData{CData1}; }
Those dabbling in multiple inheritance might be concerned about there being more than one override.
for my $parent (@ISA) { my $methname = $parent . "::CData1"; if ($self->can($methname)) { $self->$methname($newvalue); } }
Because the &UNIVERSAL::can method returns a reference to the function directly, you can use this directly for a significant performance improvement:
for my $parent (@ISA) { if (my $coderef = $self->can($parent . "::CData1")) { $self->$coderef($newvalue); } }
If you override "UNIVERSAL::can" in your own classes, be sure to return the reference appropriately.
Locking the Door and Throwing Away the Key
As currently implemented, any code within the same scope as the file-scoped lexical %ClassData can alter that hash directly. Is that ok? Is it acceptable or even desirable to allow other parts of the implementation of this class to access class attributes directly?That depends on how careful you want to be. Think back to the Cosmos class. If the &supernova method had directly altered $Cosmos::Stars or $Cosmos::Cosmos{stars}, then we wouldn't have been able to reuse the class when it came to inventing a Multiverse. So letting even the class itself access its own class attributes without the mediating intervention of properly designed accessor methods is probably not a good idea after all.
Restricting access to class attributes from the class itself is usually not enforceable even in strongly object-oriented languages. But in Perl, you can.
Here's one way:
package Some_Class; { # scope for hiding $CData1 my $CData1; sub CData1 { shift; # XXX: unused $CData1 = shift if @_; return $CData1; } } { # scope for hiding $CData2 my $CData2; sub CData2 { shift; # XXX: unused $CData2 = shift if @_; return $CData2; } }
No one---absolutely no one---is allowed to read or write the class attributes without the mediation of the managing accessor method, since only that method has access to the lexical variable it's managing. This use of mediated access to class attributes is a form of privacy far stronger than most OO languages provide.
The repetition of code used to create per-datum accessor methods chafes at our Laziness, so we'll again use closures to create similar methods.
package Some_Class; { # scope for ultra-private meta-object for class attributes my %ClassData = ( CData1 => "", CData2 => "", ); for my $datum (keys %ClassData ) { no strict "refs"; *$datum = sub { use strict "refs"; my ($self, $newvalue) = @_; $ClassData{$datum} = $newvalue if @_ > 1; return $ClassData{$datum}; } } }
The closure above can be modified to take inheritance into account using the &UNIVERSAL::can method and SUPER as shown previously.
Translucency Revisited
The Vermin class demonstrates translucency using a package variable, eponymously named %Vermin, as its meta-object. If you prefer to use absolutely no package variables beyond those necessary to appease inheritance or possibly the Exporter, this strategy is closed to you. That's too bad, because translucent attributes are an appealing technique, so it would be valuable to devise an implementation using only lexicals.There's a second reason why you might wish to avoid the eponymous package hash. If you use class names with double-colons in them, you would end up poking around somewhere you might not have meant to poke.
package Vermin; $class = "Vermin"; $class->{PopCount}++; # accesses $Vermin::Vermin{PopCount} package Vermin::Noxious; $class = "Vermin::Noxious"; $class->{PopCount}++; # accesses $Vermin::Noxious{PopCount}
In the first case, because the class name had no double-colons, we got the hash in the current package. But in the second case, instead of getting some hash in the current package, we got the hash %Noxious in the Vermin package. (The noxious vermin just invaded another package and sprayed their data around it. :-) Perl doesn't support relative packages in its naming conventions, so any double-colons trigger a fully-qualified lookup instead of just looking in the current package.
In practice, it is unlikely that the Vermin class had an existing package variable named %Noxious that you just blew away. If you're still mistrustful, you could always stake out your own territory where you know the rules, such as using Eponymous::Vermin::Noxious or Hieronymus::Vermin::Boschious or Leave_Me_Alone::Vermin::Noxious as class names instead. Sure, it's in theory possible that someone else has a class named Eponymous::Vermin with its own %Noxious hash, but this kind of thing is always true. There's no arbiter of package names. It's always the case that globals like @Cwd::ISA would collide if more than one class uses the same Cwd package.
If this still leaves you with an uncomfortable twinge of paranoia, we have another solution for you. There's nothing that says that you have to have a package variable to hold a class meta-object, either for monadic classes or for translucent attributes. Just code up the methods so that they access a lexical instead.
Here's another implementation of the Vermin class with semantics identical to those given previously, but this time using no package variables.
package Vermin; # Here's the class meta-object, eponymously named. # It holds all class data, and also all instance data # so the latter can be used for both initialization # and translucency. it's a template. my %ClassData = ( PopCount => 0, # capital for class attributes color => "beige", # small for instance attributes ); # constructor method # invoked as class method or object method sub spawn { my $obclass = shift; my $class = ref($obclass) || $obclass; my $self = {}; bless($self, $class); $ClassData{PopCount}++; # init fields from invoking object, or omit if # invoking object is the class to provide translucency %$self = %$obclass if ref $obclass; return $self; } # translucent accessor for "color" attribute # invoked as class method or object method sub color { my $self = shift; # handle class invocation unless (ref $self) { $ClassData{color} = shift if @_; return $ClassData{color} } # handle object invocation $self->{color} = shift if @_; if (defined $self->{color}) { # not exists! return $self->{color}; } else { return $ClassData{color}; } } # class attribute accessor for "PopCount" attribute # invoked as class method or object method sub population { return $ClassData{PopCount}; } # instance destructor; invoked only as object method sub DESTROY { $ClassData{PopCount}--; } # detect whether an object attribute is translucent # (typically?) invoked only as object method sub is_translucent { my($self, $attr) = @_; $self = \%ClassData if !ref $self; return !defined $self->{$attr}; } # test for presence of attribute in class # invoked as class method or object method sub has_attribute { my($self, $attr) = @_; return exists $ClassData{$attr}; }
NOTES
Inheritance is a powerful but subtle device, best used only after careful forethought and design. Aggregation instead of inheritance is often a better approach.You can't use file-scoped lexicals in conjunction with the SelfLoader or the AutoLoader, because they alter the lexical scope in which the module's methods wind up getting compiled.
The usual mealy-mouthed package-munging doubtless applies to setting up names of object attributes. For example, "$self->{ObData1}" should probably be "$self->{ __PACKAGE__ . "_ObData1" }", but that would just confuse the examples.
SEE ALSO
perltoot, perlobj, perlmod, and perlbot.The Tie::SecureHash and Class::Data::Inheritable modules from CPAN are worth checking out.
AUTHOR AND COPYRIGHT
Copyright (c) 1999 Tom Christiansen. All rights reserved.This documentation is free; you can redistribute it and/or modify it under the same terms as Perl itself.
Irrespective of its distribution, all code examples in this file are hereby placed into the public domain. You are permitted and encouraged to use this code in your own programs for fun or for profit as you see fit. A simple comment in the code giving credit would be courteous but is not required.
ACKNOWLEDGEMENTS
Russ Allbery, Jon Orwant, Randy Ray, Larry Rosler, Nat Torkington, and Stephen Warren all contributed suggestions and corrections to this piece. Thanks especially to Damian Conway for his ideas and feedback, and without whose indirect prodding I might never have taken the time to show others how much Perl has to offer in the way of objects once you start thinking outside the tiny little box that today's ``popular'' object-oriented languages enforce.HISTORY
Last edit: Sun Feb 4 20:50:28 EST 2001
Index
- NAME
- DESCRIPTION
- Class Data in a Can
- Class Data as Package Variables
- Class Data as Lexical Variables
- NOTES
- SEE ALSO
- AUTHOR AND COPYRIGHT
- ACKNOWLEDGEMENTS
- HISTORY
This document was created by man2html, using the manual pages.
Time: 05:29:09 GMT, December 24, 2015


Hackathons are programming marathons where students build services, gadgets, and apps to win prizes, and ultimately, recognition. Hackathons are a paradigm shift in technology education, and they have taken the world by storm. They encourage learning and innovation through collaboration and have produced some of the most capable thinkers and innovators of the next generation. ACM and TUDev will be throwing a 12hr hackathon titled "OwlHacks" on March 30th. Our hackathon will attract some of the top undergraduate developers, engineers, and designers in the Philadelphia area. This makes OwlHacks a great recruiting and marketing opportunity. We’re inviting companies to present their products and services for students to explore and leverage in their applications, and we would like you to be one of them.
We want you to be a part of the OwlHacks family, and we think that sponsoring OwlHacks has some clear advantages:
You have the opportunity to recruit, network with, and market your brand to some of the best student engineers on the east coast.
Although students have complete autonomy over what they choose to develop, companies may influence them through OwlHacks facilitated marketing:
Mentoring
Tech Talks
API Demos & Prizes
You have a unique ability to serve the community in a very efficient and public way by helping student engineers and designers learn how to build and utilize technology.
Your company get a vantage-point on the bleeding edge of the technological landscape; it’s a great opportunity to hear tomorrow’s startup ideas today
OwlHacks is going to be a huge undertaking, and we need all the support that we can get. There are many ways to support our cause, the most effective of which are listed below:
Donate financially to OwlHacks. This allows us the flexibility to spend money where we need it the most.
Sponsor a meal.
Sponsor tools for students to use during the event (e.g. web hosting, wi-fi, hardware).
Provide workshops & seminars to students.
Help us make OwlHacks an incredible experience for learning and invention. Our sponsorship packages, listed on the next page, outline our monetary contribution model. The higher your contribution, the more access you get to the student developers at OwlHacks. We are always looking for new and exciting things for our event. Don’t hesitate to contact us with any sponsorship ideas or suggestions you may have. Please contact us at<EMAIL_ADDRESS>if you have any questions or wish to schedule a phone call with an OwlHacks organizer.
| SILVER | GOLD | TITLE | |
|---|---|---|---|
| AMOUNTS | $600 | $800 | $1,500 |
| GENERAL | |||
| Mentors at Event | Yes | Yes | Yes |
| Reserved Sponsor Table | Half Event | Full Event | Full Event |
| API Demo | - | 5 min | 5 min |
| Tech Talk During Event | - | Yes | Yes |
| Keynote at Beginning of Event | - | 5 min | 15 min |
| RECRUITING | |||
| Material Distribution | Yes | Yes | Yes |
| Large Banners Allowed | - | Yes | Yes |
| Résumé Book of Attendees | - | Yes | Yes |
| Personal On-Site Interviews | - | - | Yes |
| BRANDING | |||
| Logo on owlhacks.com | Yes | Yes | Yes |
| Branded Prize | Yes | Yes | Yes |
| Public Mention & Thank You at Kickoff and Award Ceremony | Yes | Yes | Yes |
| "OwlHacks, co-hosted by [You]" | - | - | Yes |
| SWAG | |||
| Can Provide Swag | Yes | Yes | Yes |


Haunt Digital
2014
I was fortunate enough to work with the awesome people at Haunt Digital in Wellington for a few months in 2014 during my final year of study. Below is a selction of sites & concepts I worked on during my time there. Check out the Maori History site here.


Dear sir /madam My name is miss Yssouf Nneoma Woloso Age 26 years old Its the will of GOD that i write to you,How was your day?.Mine is not good because i live in the refugee camp here in Dakar Senegal. In the camp we are only allowed to go out only with pemission from UN camp master .Its just like one staying in the prison and i hope by Gods grace i will come out here with your help. I am from Abidjan Ivory Coast in west Africa and my late father Dr Woloso Amadou was known as a diamond delaer. As a refugee here i don't have any right or freedom of my own or privilledge to do any thing because of the law of this country.I want to go back to my studies because i only attended my first year before the traggic incident that lead to my being in this situation now took place. Please listen to this,i have some deposit certificate of my late father's properties here with me because when he was alive he deposited some amount of money in a security and finance company here which he used my name as the next of kin, the amount in question is Seven Million Five Hundred Thousand united states Dollars. So i will like you to help me transfer this money to your account and from it ,you can send some money for me to get travelling documents and air ticket to come over to meet with you. I kept this secret to people in the camp here . So in the light of above, i will like you to please send to me your currect phone and House address so that i will mail to you the contact of the scurity and finance company for you to confirm from the faninace company and tell them you are interested in helping me transfar the money to your accounts. they should tell you the necessary requirement needed for the transfar. Out of this money i will give 15 percent for your help while 10 percent will be for the expensis you incure during the transaction. I like honest and understanding people,truthful a man and woman of vision and hardworking With love.God bless you. Sincerely, MissYssouf Nneoma Woloso. you can contact me at my personel email nneoma70@hotmail.com.


Quick guide for using Docker (v1)¶
Docker allows software packages, called containers, to be ran. E3SM Diagnostics has a Docker container that makes running the software easier than traditional methods. Any machine that has Docker installed can use the instructions below to run E3SM Diagnostics.
Obtaining the container image¶
1. Make sure that Docker is installed and running on your machine. To check this, run the command below and you should see some output.
docker info
View all of the
e3sm_diags
images.docker images | grep e3sm_diags
If the version you want to use is already available, then please continue to step 4.
Otherwise, you’ll need to download the image you want, shown in step 3.
3. If the specific version you want or the latest
image is not shown,
download it. You can view all of the images available on the
e3sm_diags Docker Hub.
Below, we are getting the image with the latest tag:
docker pull e3sm/e3sm_diags:latest
Running a quick test¶
Since you probably don’t have much sample data on your machine, below are the steps to run a quick test. If you do have data, please go to the “Running more diagnostics” section below.
Clone the
e3sm_diags
repo, and go to the test directory.git clone https://github.com/E3SM-Project/e3sm_diags.git cd e3sm_diags/tests/system/
wget
orcurl
the script to run the container.wget https://raw.githubusercontent.com/E3SM-Project/e3sm_diags/master/acme_diags/container/e3sm_diags_container.py # Or use this: curl -O https://raw.githubusercontent.com/E3SM-Project/e3sm_diags/master/acme_diags/container/e3sm_diags_container.py
Run your diagnostics and examine the sample output.
python e3sm_diags_container.py --docker -p all_sets.py -d all_sets.cfg
Tip: You can select the version of the container you want to run with the --container_version
argument.
If this argument isn’t defined, it defaults to the latest
container.
python e3sm_diags_container.py --docker --container_version v1.6.0 -p myparams.py
Open the html below to view the results.
all_sets_results/viewer/index.html
Running more diagnostics¶
To run other, more interesting diagnostics, you must download the data from one of our supported machines (ALCF Cooley, NERSC Cori and others). For more information on the format of the input data, please see the input data requirements.
Below are the paths to the observational data:
- Climatology data (6GB):
NERSC:
/global/project/projectdirs/acme/acme_diags/obs_for_e3sm_diags/climatology/
ALCF:
/lus/theta-fs0/projects/ClimateEnergy_3/e3sm_diags/obs_for_e3sm_diags/climatology/
- Time-series data (145GB):
NERSC:
/global/project/projectdirs/acme/acme_diags/obs_for_e3sm_diags/time-series/
ALCF:
/lus/theta-fs0/projects/ClimateEnergy_3/e3sm_diags/obs_for_e3sm_diags/time-series/
We also have sample model data as well. You can use your own model data as well,
either climatology or time-series files created via nco
.
Again, if you want to use your own data, please see the
input data requirements.
- Climatology data (42GB):
We have data from three models in these directories, from about 11.5GB to 19GB.
NERSC:
/global/project/projectdirs/acme/acme_diags/test_model_data_for_acme_diags/climatology/
ALCF:
/lus/theta-fs0/projects/ClimateEnergy_3/e3sm_diags/test_model_data_for_e3sm_diags/climatology/
- Time-series data (107GB):
We have E3SM v1 data (94GB) and CESM1-CAM5 CMIP data (14GB).
NERSC:
/global/project/projectdirs/acme/acme_diags/test_model_data_for_acme_diags/time-series/
ALCF:
/lus/theta-fs0/projects/ClimateEnergy_3/e3sm_diags/test_model_data_for_e3sm_diags/time-series/
Once the data is downloaded you can follow one of the many examples that we have.
Some points to remember:
You must change the
reference_data_path
andtest_data_path
accordingly.Every instance of
e3sm_diags
should bepython e3sm_diags_container.py --docker
.
Ex: Use
python e3sm_diags_container.py --docker -p myparams.py
instead ofe3sm_diags -p myparams.py
.


{% extends "description.html" %} {# Make sure to number your filenames if you need them to be in a specific order #} {# Ordering needs to start at 1 (not 0) #} {% set id="ln-macaroons"%} {# id must be unique and follow the rules for ids in css https://www.w3.org/TR/CSS21/syndata.html#characters #} {% set project="Lightning" %} {# Use proper-case (ex. Bitcoin, not bitcoin) #} {% set sub_project="Macaroons" %} {# set to False or "" if not using #} {% set simple_desc="Login to your favorite websites using Lightning" %} {# Keep this short (~50 characters) #} {% set details=True %} {% set further_reading=False %} {% block at_a_glance %}
Macaroons allow any service (not just websites) to provide you with a bearer token that you can use to identify yourself and optionally share with others. This way you can pay for a service with Lightning and later use that service at your leisure by providing it with your Macaroon to prove you paid previously.
{% endblock at_a_glance %} {% block status %}It's in development and has recently made its way into a piece of Lightning software called LND.
{% endblock status %} {% block future %} {% endblock future %} {% block vs_alts %} {% endblock vs_alts %} {% block further_reading %} {% endblock further_reading %}


Abstract logger class with minimal requirements to all logger. More...
#include <logger.h>
Public Member Functions | |
| virtual void | logStep (const unsigned int &, const arma::vec &, const arma::vec &, blearner::Baselearner *, const double &, const double &)=0 |
| Log current step of compboost iteration dependent on the child class. More... | |
| virtual bool | reachedStopCriteria () const =0 |
| Class dependent check if the stopping criteria is fulfilled. More... | |
| virtual arma::vec | getLoggedData () const =0 |
| Return the data stored within the logger. More... | |
| virtual void | clearLoggerData ()=0 |
| Clear the logger data. More... | |
| virtual std::string | printLoggerStatus () const =0 |
| Print status of current iteration into the console. More... | |
| bool | getIfLoggerIsStopper () const |
| Just a getter if the logger is also used as stopper. More... | |
| virtual | ~Logger () |
Protected Attributes | |
| bool | is_a_stopper |
| Tag if the logger is used as stopper. More... | |
Abstract logger class with minimal requirements to all logger.
This class is meant to define some minimal functionality any logger must have! The key of the logger is nut only the logging of the process, but also to be able to define a logger as stopper to force an early stopping if one or all of the used logger have reached a stopping criteria. This is more explained within the child classes.
Note that this minimal functionality mentioned above differs for every class and is explained within the specific class documentation.
|
virtual |
|
pure virtual |
Clear the logger data.
Implemented in logger::LoggerTime, logger::LoggerOobRisk, logger::LoggerInbagRisk, and logger::LoggerIteration.
| bool logger::Logger::getIfLoggerIsStopper | ( | ) | const |
Just a getter if the logger is also used as stopper.
Getter if the logger is used as stopper.
bool
which says true
if it is a logger, otherwise false
|
pure virtual |
Return the data stored within the logger.
Implemented in logger::LoggerTime, logger::LoggerOobRisk, logger::LoggerInbagRisk, and logger::LoggerIteration.
|
pure virtual |
Log current step of compboost iteration dependent on the child class.
Implemented in logger::LoggerTime, logger::LoggerOobRisk, logger::LoggerInbagRisk, and logger::LoggerIteration.
|
pure virtual |
Print status of current iteration into the console.
Implemented in logger::LoggerTime, logger::LoggerOobRisk, logger::LoggerInbagRisk, and logger::LoggerIteration.
|
pure virtual |
Class dependent check if the stopping criteria is fulfilled.
Implemented in logger::LoggerTime, logger::LoggerOobRisk, logger::LoggerInbagRisk, and logger::LoggerIteration.
|
protected |
Tag if the logger is used as stopper.


{% extends 'page.html' %} {% block content %}
There are different hashtags that this app listens from Mowgli. To add a new hashatag to listen to, make changes in mowglibot and add a section here.
#success
Sharing the successes across the organization!
#LesssonsLearnt
Collective lessons learned from our unique experiences
#NowReading
Share the interesting articles and books your come across!
#NowListening
We love diverse ♪ music and let's share it all! ♫


Tutorials and examples
API
Some examples for various models.
Bands¶
Body-oriented mill¶
Mills¶
Boundary clusters in a disk¶
Volume exclusion¶
Gallery generated by Sphinx-Gallery


From your customer profile you can check your tickets status, create a new ticket and modify your personal information
Have a compliant about a target? Create your ticket
From your admin profile you have customer functionality and you can also access all the system administration functionality
Have a compliant about a target? Create your ticket
From your team profile you can access all the team related functionality
Do you want to see the advancement status of the tickets your team is working on?


{% extends "layout_bsa.html" %} {% block page_title %} Help paying for NHS Costs prototype {% endblock %} {% block content %} Back This section is Where you live {% if thirdparty %} Is {firstname} a student living away from home? {% else %} What is the start and end dates of your rental agreement? {% endif %} Start date End date {% endblock %}
This section is Where you live


Or Also GDG-Security is one of github organization try to create open source based on what people need when they use there laptops we try also to be creative day by day . Now we are a team of 10 person the creator of this organization called Yezz123 or (Yasser Tahiri) you can check all what u want on project or follow us on social media.


Predefined HTML
without language versions

 node_title

 node_title

with language versions

 node_title node_title

 node_title node_title

NOTE: if you wish to set a custom icon for a node just use the background-image style property (on the  node).
Nested XML
WITHOUT language versions
<xml version="1.0" encoding="utf-8" ?> <root> <item id="node_id" [state="closed|open" hasChildren]> <content> <name [icon="path_to_icon"]><![CDATA[node_title]]></name> </content>  </item> </root>
WITH language versions
<xml version="1.0" encoding="utf-8" ?> <root> <item id="node_id" [state="closed|open" hasChildren]> <content> <name lang="language_name" [icon="path_to_icon"]> <![CDATA[node_title]]> </name> <name lang="language_name" [icon="path_to_icon"]> <![CDATA[node_title]]> </name> </content>  </item> </root>
NOTE:
- if the icon attribute (if set) does not contain a "/" the icon is looked up in the current theme directory (so if the icon is in the same folder as the file displaying the tree use "./")
- if the state attribute is present the node is forced in the specified state
- if the hasChildren attribute is present, the output node is displayed as having children even if it does not (useful for async)
- all other attributes of the item node get copied to the
 node in the output HTML (for example title or rel)
- all attributes (except language and icon) of the name node get copied to the  node in the output HTML (for example href)
Flat XML
WITHOUT language versions
<xml version="1.0" encoding="utf-8" ?> <root> <item id="node_id" parent_id="parent_node_id" [state="closed|open" hasChildren]> <content> <name [icon="path_to_icon"]><![CDATA[node_title]]></name> </content> </item>  </root>
WITH language versions
<xml version="1.0" encoding="utf-8" ?> <root> <item id="node_id" parent_id="parent_node_id" [state="closed|open" hasChildren]> <content> <name lang="language_name" [icon="path_to_icon"]> <![CDATA[node_title]]> </name> <name lang="language_name" [icon="path_to_icon"]> <![CDATA[node_title]]> </name> </content> </item>  </root>
NOTE:
- in async mode, do not set the parent_id attribute
- if the icon attribute (if set) does not contain a "/" the icon is looked up in the current theme directory (so if the icon is in the same folder as the file displaying the tree use "./")
- if the state attribute is present the node is forced in the specified state
- if the hasChildren attribute is present, the output node is displayed as having children even if it does not (useful for async)
- all other attributes of the item node get copied to the
 node in the output HTML (for example title or rel)
- all attributes (except language and icon) of the name node get copied to the  node in the output HTML (for example href)
JSON
WITHOUT language versions
{ attributes: { id : "node_identificator", [attribute : "attribute_value"] }, state: "closed" or "open", data: "node_title", children: [ // an array of child nodes objects ] } // data can also be in the form data : { title : "node_title", icon : "path_to_icon", attributes : {"key" : "value", ... } }
WITH language versions
{ attributes: { id : "node_identificator", [attribute : "attribute_value"] }, state: "closed" or "open", data: { "language_name" : "node_title", "language_name" : "node_title", ... }, children: [ // an array of child nodes objects ] } // each item in the data object can also be in the form "language" : { title : "node_title", icon : "path_to_icon", attributes : {"key" : "value", ... } }
NOTE:
- if path_to_icon (if set) does not contain a "/" the icon is looked up in the current theme directory (so if the icon is in the same folder as the file displaying the tree use "./")
- if the state property is present the node is forced in the specified state
- all members of the attributes object node get copied to the
 node in the output HTML as attributes (for example title or rel)
- all attributes in any data object get copied to the  node