| Package | flare.vis.operator.layout |
| Class | public class RadialTreeLayout |
| Inheritance | RadialTreeLayout Layout Operator |
Shapes.WEDGE
and the layout instance should
have the useNodeSize property set to false.
The algorithm used is an adaptation of a technique by Ka-Ping Yee,
Danyel Fisher, Rachna Dhamija, and Marti Hearst, published in the paper
Animated Exploration of
Dynamic Graphs with Radial Layout, InfoVis 2001. This algorithm computes
a radial layout which factors in possible variation in sizes, and maintains
both orientation and ordering constraints to facilitate smooth and
understandable transitions between layout configurations.
| Property | Defined by | ||
|---|---|---|---|
| angleWidth : Number The angular width of the layout (in radians, default is 2 pi).
| RadialTreeLayout | ||
| autoScale : Boolean Flag indicating if the layout should automatically be scaled to
fit within the layout bounds.
| RadialTreeLayout | ||
| enabled : Boolean Indicates if the operator is enabled or disabled.
| Operator | ||
| layoutAnchor : Point The layout anchor, used by some layout instances to place an
initial item or determine a focal point.
| Layout | ||
| layoutBounds : Rectangle The layout bounds for the layout.
| Layout | ||
| layoutRoot : DataSprite
The layout root, the root node for tree layouts.
| Layout | ||
| layoutType : String = "null" The type of layout and axes.
| Layout | ||
| parameters : Object
Sets parameter values for this operator.
| Operator | ||
| radiusIncrement : Number The radius increment between depth levels.
| RadialTreeLayout | ||
| sortAngles : Boolean Flag determining if nodes should be sorted by angles to help
maintain ordering across different spanning-tree configurations.
| RadialTreeLayout | ||
| startAngle : Number The initial angle for the radial layout (in radians).
| RadialTreeLayout | ||
| useNodeSize : Boolean Flag indicating if node's
size property should be
used to determine layout spacing. | RadialTreeLayout | ||
| visualization : Visualization
The visualization processed by this operator.
| Operator |
| Method | Defined by | ||
|---|---|---|---|
|
RadialTreeLayout(radius:Number, sortAngles:Boolean = true, autoScale:Boolean = true)
Creates a new RadialTreeLayout.
| RadialTreeLayout | ||
|
applyParameters(op:IOperator, params:Object):void
[static]
Static method that applies parameter settings to an operator.
| Operator | ||
|
clearEdgePoints():void
Strips all EdgeSprites in a visualization of any control points.
| Layout | ||
|
Hides the axes.
| Layout | ||
|
operate(t:Transitioner = null):void
Performs an operation over the contents of a visualization.
| Layout | ||
|
setup():void
Setup method invoked whenever this operator's visualization
property is set.
| Operator | ||
|
Reveals the axes.
| Layout | ||
|
[static]
Updates all edges to be straight lines.
| Layout |
| Method | Defined by | ||
|---|---|---|---|
|
autoAnchor():void
Automatically-generate an anchor point.
| Layout | ||
|
layout():void
Calculates the spatial layout of visualized items.
| RadialTreeLayout | ||
|
minAngle(a1:Number, a2:Number):Number
Returns an angle value that minimizes the angular distance
between a reference angle and a target angle.
| Layout |
| Constant | Defined by | ||
|---|---|---|---|
| CARTESIAN : String = "cartesian" [static] Constant indicating Cartesian (x, y) coordinates.
| Layout | ||
| DEFAULT_RADIUS : int = 50 [static] The default radius increment between depth levels.
| RadialTreeLayout | ||
| PARAMS : String = "radialTreeLayoutParams" [static] Property name for storing parameters for this layout.
| RadialTreeLayout | ||
| POLAR : String = "polar" [static] Constant indicating polar (radius, angle) coordinates.
| Layout |
| angleWidth | property |
angleWidth:Number
[read-write]The angular width of the layout (in radians, default is 2 pi).
Implementation public function get angleWidth():Number
public function set angleWidth(value:Number):void
| autoScale | property |
autoScale:Boolean
[read-write]Flag indicating if the layout should automatically be scaled to fit within the layout bounds.
Implementation public function get autoScale():Boolean
public function set autoScale(value:Boolean):void
| radiusIncrement | property |
radiusIncrement:Number
[read-write]The radius increment between depth levels.
Implementation public function get radiusIncrement():Number
public function set radiusIncrement(value:Number):void
| sortAngles | property |
sortAngles:Boolean
[read-write]Flag determining if nodes should be sorted by angles to help maintain ordering across different spanning-tree configurations. This sorting is important for understandable transitions when using a radial layout of a general graph. However, it is unnecessary for tree structures and increases the running time of layout.
Implementation public function get sortAngles():Boolean
public function set sortAngles(value:Boolean):void
| startAngle | property |
startAngle:Number
[read-write]The initial angle for the radial layout (in radians).
Implementation public function get startAngle():Number
public function set startAngle(value:Number):void
| useNodeSize | property |
useNodeSize:Boolean
[read-write] Flag indicating if node's size
property should be
used to determine layout spacing. If a space-filling radial
layout is desired, this value must be false for the layout
to be accurate.
public function get useNodeSize():Boolean
public function set useNodeSize(value:Boolean):void
| RadialTreeLayout | () | constructor |
public function RadialTreeLayout(radius:Number, sortAngles:Boolean = true, autoScale:Boolean = true)
Creates a new RadialTreeLayout.
Parametersradius:Number — the radius increment between depth levels
|
|
sortAngles:Boolean (default = true ) — flag indicating if nodes should be sorted by angle
to maintain node ordering across spanning-tree configurations
|
|
autoScale:Boolean (default = true ) — flag indicating if the layout should automatically
be scaled to fit within the layout bounds
|
| layout | () | method |
protected override function layout():void
Calculates the spatial layout of visualized items. Layout operators override this method with their layout implementations.
| DEFAULT_RADIUS | constant |
public static const DEFAULT_RADIUS:int = 50
The default radius increment between depth levels.
| PARAMS | constant |
public static const PARAMS:String = "radialTreeLayoutParams"
Property name for storing parameters for this layout.


class Solution: def minimumSize(self, nums: List[int], maxOperations: int) -> int: def operation(balls: int)-> int: ans = 0 for x in nums: if x > balls: ans += (x - 1) // balls # print(balls, ans) return ans left, right = 1, max(nums) # print(left, right) while left < right: mid = (left + right) // 2 if operation(mid) <= maxOperations: right = mid else: left = mid + 1 # print("lr", left, right) return left


Convicted agent Butina accepts Russia job offer: TASS
MOSCOW (Reuters) - A Russian agent briefly jailed in the United States and then deported back to Moscow has accepted a state job to defend Russians imprisoned abroad, TASS news agency reported on Friday.
Maria Butina, 31, pleaded guilty in a U.S. court last December to one count of conspiring to act as a foreign agent for Russia by infiltrating a gun rights group and influencing conservative activists and Republicans.

Earlier this week, Russian human rights commissioner Tatyana Moskalkova offered Butina a position in the commission during her first public appearance since she was deported back to Moscow last month.
Butina did not say at the time whether she accepted the offer.
“She accepted the proposal,” TASS quoted Moskalkova on Friday as saying, without saying when Butina would start her new job.
Butina did not immediately respond to a request for comment.
Her case has further strained relations between Moscow and Washington, already soured over issues including U.S. allegations of Russian election meddling and Moscow’s annexation of Crimea. Russia denies any interference in U.S. elections.


WITNESS LIST Insurance Committee April 6, 1999-10:30A HB 499 Against: Geiger, Richard (Association of Fire and Casualty Companies of Texas) Huxel, Bob (Farmers Insurance Group of Companies) On: Burnbaum, Burny (Self) HB 1092 For: Aycock, Colleen (Self) Burnbaum, Burny (Self) Schneider, Rob (Consumers Union - Southwest Regional Office) Against: Huxel, Bob (Farmers Insurance Group of Companies) Thompson, Jay (AFACT) Thornton, Bill (Self and Union Standard Insurance Company; Union Standard Lloyds) On: Bordelon, Rod (OPIC) HB 1637 For: Flores, Fred (Self) Graves, William (Progressive County Mutual) Hernandez, Michael (Self) Huxel, Bob (Farmers Insurance Group) Kosub, Frank (Self) Taylor, Larry (Self) Against: Murphy, William (Automobile Insurance Agents of Texas) Schneider, Rob (Consumers Union) Thornton, Bill (Self and Union Standard Insurance Company; Union Standard Lloyds) On: Bordelon, Rod (OPIC) Durden, David (TDI) HB 1935 For: Geiger, Richard (Association of Fire and Casualty Companies in Texas) HB 2376 For: Schneider, Rob (Consumers Union) HB 2478 For: Schneider, Rob (Consumers Union) HB 2789 For: Geiger, Richard (Seaburg and Smith) Geiger, Richard (Zale Indemnity Company) Hudson, Greg (Republic Industries, Inc.) Neeley, Karen (Independent Bankers Association of Texas) Price, Rayford (Consumer Credit Insurance Association) Tooley, Kenneth (Texas Association of Life and Health Underwriters) On: Davis, Will (Texas Association of Life and Health Insurers) Thompson, Jay (Reliable Life and Capital County Mutual) HB 2790 For: Burner, Burnie (Texas Association of Mutual Insurance Companies and Long, Burner, Parks & Sealy, PC) Gilbert, Bo (Independent Insurance Agent of Texas) Joyce, Stephen (Reliable Life Insurance Company and Capitol; County Mutual Fire Insurance Company) Neeley, Karen (Independent Bankers Association of Texas) Pollard, Mike (Texas Association of Life and Health Insurers) Ruiz, J. Joe (Reliable Life Insurance Company; Capital County Mutual) Thompson, Jay (AFACT/Reliable Life/Capitol County Mutual) Tooley, Ken (Texas Association of Life Underwriters) Against: Elam, Tom (Self and United Funeral Directors Benefit Life Insurance Company) Garcia, Carol (Self) Hooser, Greg (Texas Association of Insurance Officers) On: Davis, Brian (Directors Investment Group) HB 2903 Against: Davis, Will (Independent County Mutual Insurance Co.; American National Property and Casualty) Geiger, Richard (Association of Fire and Casualty Companies in Texas) Graves, William (Progressive County Mutual Insurance Co.) Huxel, Bob (Farmers Insurance Group of Companies) Watkins, Robert (State Farm Insurance Companies) On: Durden, David (Texas Department of Insurance) HB 2941 For: Lamb, Paul (Self and Signature Group) HB 3017 For: Cobb, Ronald (American Insurance Association) Davis, Will (USAA and American National Property and Casualty) Gilbert, Bo (Independent Insurance Agents of Texas) Huxel, Bob (Farmers Insurance Group of Companies) Simpson, Robert (State Farm Insurance Co.) Watkins, Robert (State Farm Insurance Companies) Against: Schneider, Rob (Consumers Union) On: Walker, Craig (Foundation Repair Association of Texas) HB 3099 For: Akins, Karen (Trans Texas Alliance) Butler, Patrick (NOW) Kallerman, Richard (Self) Sommerfeld, Jeanne (Self and Texas NOW) Against: Thompson, Jay (AFACT) On: Bordelon, Rod (OPIC) HB 3179 For: Barron, Connie (Texas Medical Association) Against: Kyles, Regina (Self) Patterson, Jerry (Texas Association of Health Plans) Thompson, Jay (TALHI) HB 3180 For: Barron, Connie (Texas Medical Association) Against: Davis, Will (Texas Association of Life and Health Insurers) Patterson, Jerry (Texas Association of Life and Health Plans) HB 3359 For: Geiger, Richard (Association of Fire and Casualty Companies in Texas)


class: center, middle, inverse, title-slide # Recap II ### The R Bootcamp
Twitter:
@therbootcamp
### April 2018 --- # Essentials of the R language .pull-left5[ >"To understand computations in R, two slogans are helpful:

 >###(1) Everything that exists is an object and >###(2) everything that happens is a function call." ] .pull-right5[

John Chambers
  Author of S and developer of R
 statweb.stanford.edu
 ] --- .pull-left45[ # Objects >###"Everything in R is an object"
 >
*John Chambers*

 + R's objects are have **content and attributes**. <br2> + The **content can be anything** from numbers or strings to functions or complex data structures. <br2> + Attributes often encompass **names**, **dimensions**, and the **class or type** of the object, but other attributes are possible. <br2> + Practically all data objects are equipped with those **three essential attributes**. ] .pull-right5[

  ] --- # Vectors R's most **basic (and most simple) data format** - even single values (aka **scalars**) are implemented as vectors. .pull-left45[ ```r # creating a vector (incl. names) my_vec <- c(t_1 = 1.343, t_2 = 5.232) # naming vectors my_vec <- c(t_1 = 1.343, t_2 = 5.232) names(my_vec) <- c("new_1","new_2") # evaluting inherent attributes names(my_vec) length(my_vec) typeof(my_vec) ``` ] .pull-right5[

 ] --- # Types Vectors contains elements of only one type. Most often one of the four **basic types**: `integer`, `double`, `numeric`, and `character`. You can **test** the type using `typeof()` or the type-specific `is.*()`, e.g., `is.integer()`. .pull-left45[ ```r # numeric vectors my_vec <- c(1.343, 5.232) typeof(my_vec) ``` ``` ## [1] "double" ``` ```r # integer vectors (L avoids coercion) my_vec <- c(1L, 7L, 2L) typeof(my_vec) ``` ``` ## [1] "integer" ``` ] .pull-right45[ ```r # logical vectors my_vec <- c(TRUE, FALSE) typeof(my_vec) ``` ``` ## [1] "logical" ``` ```r # character vectors my_vec <- c('a', 'hello', 'world') typeof(my_vec) ``` ``` ## [1] "character" ``` ] --- # `data_frame`s .pull-left45[ * Data frames (and its variants, e.g., **tibble**s) are R's **main data format**. * **Data frames are lists** with specific **requirements**: + Every element must be a vector. + The lengths of the vectors must be equal (or multiples of another). * Use `data_frame()` and `as_data_frame` to create or to coerce to data frame, to `tibble` to be exact. ] .pull-right45[

 ] --- # Accessing & changing data frames (and lists) Data frames (and lists) are best accessed using **names** and the `$`-operator. This, of course, implies that you followed good practice and named the individual elements in the data object. ```r # define data frame my_df <- data_frame('v_1' = c('A', 'B'), 'v_2' = c(1, 2)) ``` .pull-left45[ ```r # One bad, two correct ways to subset my_df[1] ; my_df[[1]] ; my_df[['v_1']] ``` ``` ## # A tibble: 2 x 1 ## v_1 ## <chr> ## 1 A ## 2 B ``` ``` ## [1] "A" "B" ``` ``` ## [1] "A" "B" ``` ] .pull-right45[ ```r # Best use $-operator to access my_df$v_1 ``` ``` ## [1] "A" "B" ``` ```r # and change my_df$v_1 <- c('Y', 'Z') my_df$v_1 ``` ``` ## [1] "Y" "Z" ``` ]  --- # Example ```r c(22, 45, 32, 18, 19, 24) age <- c(22, 45, 32, 18, 19, 24) as.character(age) age <- as.character(age) mean(age) ``` --- # Functions Functions are objects that conduct operations on objects using objects. Functions have 3 elements: + **Name**: Used to call (execute) the function. + **Argument(s)**: Objects that the function needs to do its job. May have *default arguments*. + **Expression**: R code that does the job. .pull-left5[ ```r # Defining a function that computes # the mean or median my_stat <- function(x, method = 'mean'){ # detect and run method if(method == "mean") return(mean(x)) if(method == "median") return(median(x)) } # Define object my_vec <- c(1, 4, 6, 3, 7, 5, 12, 9) ``` ] .pull-right45[ ```r # Runnning our functions mean(x = my_vec) ``` ``` ## [1] 5.875 ``` ```r my_stat(x = my_vec, method = 'mean') ``` ``` ## [1] 5.875 ``` ```r my_stat(x = my_vec, method = 'median') ``` ``` ## [1] 5.5 ``` ] --- # Help .pull-left5[ **help files** (and **vignettes**) are very useful. Pay attention to... - `Usage` - shows function's use, its arguments and their defaults. - `Arguments` - explains arguments, and their `type`/`class` - `Value` - explains what the function returns - `Examples` - ```r # To access help files ?name_of_function # search help files ??name_of_function ``` ] .pull-right45[

  ] --- # The almighty **tidyverse** Among its many packages, R contains a collection of high-performance, easy-to-use packages (libraries) designed specifically for handling data know as the [tidyverse](https://www.tidyverse.org/). The tidyverse includes: 1. `ggplot2` -- creating graphics. 2. `dplyr` -- data manipulation. 3. `tidyr` -- tidying data. 4. `readr` -- read wild data. 5. `purrr` -- functional programming. 6. `tibble` -- modern data frame.

  --- .pull-left4[ # How do we wrangle data in R? Answer: dplyr Anytime you want to transform, organize, or aggregate data, use `dplyr`  ] .pull-right5[  ] --- .pull-left35[ # dplyr `dplyr` is a combination of 3 things: 1. **`objects`** like dataframes 2. **`functions`** that **do** things to objects. 3. **`pipes`** `%>%` that string together objects and verbs
  ] .pull-right6[

 ## The pipe %>% <br2> `dplyr` makes extensive use of the 'pipe' `%>%` which passes objects between functions.

 ```r data %>% # Start with data, AND THEN... FUN1 %>% # Do FUN1, AND THEN... FUN2 %>% # Do FUN2, AND THEN... FUN3 %>% # Do FUN3, AND THEN... group_by(x, y) %>% # Group by variables x, y summarise( VAR_A_New = FUN4(X), VAR_B_New = FUN5(Y), VAR_C_New = FUN6(Z), ) ) ``` ] --- ## There are tons of statistical packages in R! .pull-left35[

 | Package| Models| |------:|:----| | `afex`| Anovas| | `rpart`| Decision Trees| | `lme4`| Mixed effects regression| | `BayesFactor`| Bayesian statistics| | `igraph`| Cluster analyses| | `neuralnet`| Neural networks| ] .pull-right6[  ] --- # Statistics .pull-left5[ | Test| R Function| |:------|:----| | `formula`|The dependent variable and one or more independent variables| | `data`| The dataframe containing variables| | `subset` | Optional subset of data to test | ```r trial_X ``` ``` ## id sex age arm y_primary y_secondary ## 1 1 m 35 1 50 1 ## 2 2 f 42 2 78 1 ## 3 3 f 24 1 46 0 ## 4 4 m 56 2 97 1 ## 5 5 f 49 1 74 1 ``` ] .pull-right45[ ```r TEST(formula = Y ~ X1 + X2 + ..., data = DATA, subset = SUBSET, ...) ``` ### Examples ```r # T-test # DV = y_primary, IV = arm t.test(formula = y_primary ~ arm, data = trial_X) # Regression # DV = y_secondary, IV = arm, sex, age # Subset = only id > 50 glm(formula = y_secondary ~ arm + sex + age, data = trial_X, subset = id > 50) ``` ] --- .pull-left35[

 ## Exploring statistical objects Assign the results of a statistical function to a new object, then use *generic* functions such as `print()`, `summary()`, `predict()` and `plot()` to explore it. ```r # Create statistical object my_obj <- FUN(formula = ..., data = ...) names(my_obj) # Elements print(my_obj) # Print summary(my_obj) # Summary plot(my_obj) # Plotting predict(my_obj, ..) # Predict ``` ] .pull-right6[

 ```r # Create a glm object chick_glm <- glm(formula = weight ~ Time, data = ChickWeight) # Print the object names(chick_glm) ``` ``` ## [1] "coefficients" "residuals" "fitted.values" "effects" "R" ## [6] "rank" "qr" "family" "linear.predictors" "deviance" ## [11] "aic" "null.deviance" "iter" "weights" "prior.weights" ## [16] "df.residual" "df.null" "y" "converged" "boundary" ## [21] "model" "call" "formula" "terms" "data" ## [26] "offset" "control" "method" "contrasts" "xlevels" ``` ```r ## Access elements chick_glm$coefficients ``` ``` ## (Intercept) Time ## 27.467 8.803 ``` ] --- # What is machine learning? .pull-left6[ ### Algorithms autonomously learning from data. Given data, an algorithm tunes its *parameters* to match the data, understand how it works, and make predictions for what will occur in the future.  ] .pull-right4[  ] --- # How do I do machine learning in R? .pull-left6[ In principle, it's a lot like evaluating statistical functions. Install the necessary package, evaluate the model function, explore the results. ```r # Create training and test data data_train <- ... data_test <- ... # Train models on training data model_A <- A_fun(formula = y ~ ., data = data_train) # Model A predictions pred_A <- predict(model_A, newdata = data_test) # Calculate Model A error pred_err_A <- mean(abs(pred_A - data_test$y)) # Compare to Models B, C, D... ``` ] .pull-right35[ If you're really into machine learning, the `caret` package can automate much of the the machine learning process.  ] --- # Today
Schedule


For this project, our entire group wanted to focus on games and how it can affect relationships. We've all had a game night that has gone horrendously wrong for numerous of reasons. Someone got too invested over a party game, the rules were explained poorly so no one played the game properly, or there was an inbalance between player strengths, causing the novice players to dominate the amateur players. We wanted to delve more into why this occurs and if there might be some correlation between games and relationships.


Tic Tac Toe Settings
Player 1 Name:
Player 2 Name:
Grid Size:
Needed To Win:
Number of Tournament Rounds:


Positioning in CSS
A short blog entry explaining the difference between relative, absolute and fixed positioning
Identity, Values and Strengths Exploration
Asking myself some insightful questions
Learning Plan
A self-directed learning plan to help me stay accountable
Emotional Intelligence
A reflection on EQ and it's importance
JS Fundamentals
An explanation of some JavaScript fundamentals
Mindset
Revisiting neuroplasticity and growth mindset
Problem Solving
Pseudocode, rubber ducks and everything in between
Foundations Reflection
A final reflection on the foundations process
Coming Soon...


All javascript files in the "excludes" directories are not used. They are only for specifying interface contracts.


Meet the Parents (2000) Robert De Niro, Ben Stiller, Blythe Danner, Teri Polo, James Rebhorn, Jon Abrahams, Owen Wilson, Phyllis George, Kali Rocha, Tom McCarthy, Nicole DeHuff. Screenplay by Jim Herzfeld, John Hamburg, story by Greg Glienna, Mary Ruth Clarke. Directed by Jay Roach. 108 minutes. Rated PG-13, 3.5 stars (out of five stars)
Review by Ed Johnson-Ott, NUVO Newsweekly www.nuvo.com Archive reviews at http://us.imdb.com/ReviewsBy?Edward+Johnson-Ott To receive reviews by e-mail at no charge, send subscription requests to<EMAIL_ADDRESS>or e-mail<EMAIL_ADDRESS>with the word "subscribe" in the subject line.
"Meet the Parents" is often funny and occasionally hilarious. I laughed a lot at the story of a young man's nightmarish weekend with his potential in-laws, but not as much as the people around me. Part comedy of manners, part slapstick farce, the film does everything it sets out to do, yet I still felt vaguely unsatisfied. Finally, I realized what was troubling me.
I've seen this type of farce done better on "Frasier." Remember the episode where the Crane family tried to help Daphne rid herself of an old flame, only to get caught in an ever-increasing spiral of lies? Or the one where Niles and Frasier vied for the sole open slot at an upper crust men's club? How about the one where Niles mistakenly thought his wife was having an affair with her fencing instructor and ended up in a duel with the man, while his brother and a maid haplessly tried to conquer a multi-language barrier? Or the one set at the ski lodge, where five characters spent a sexually fevered night slipping from one room to another, repeatedly ending up with the wrong person?
Each of those episodes featured tighter, more inventive plots and deeper character development than "Meet the Parents." The comedy is a spirited, relatively satisfying affair, but with names like Robert De Niro and Ben Stiller attached to the project, I expect more.
Stiller plays a Chicago nurse named Greg Focker (and yes, the script milks his last name to the hilt). Greg is on the verge of proposing marriage to schoolteacher Pam Byrnes (Teri Polo) when she announces her sister's engagement to a man who took the old-fashioned approach, going to the father to secure his approval before popping the question.
Not to be outdone, Greg decides to accompany Pam to the wedding so that he, too, can ask for his beloved's hand. He meets Pam's charming mother, Dina (Blythe Danner) and her imposing father, Jack (De Niro) at their sprawling home. Greg soon learns two things about Jack. First, he is fiercely protective of Pam. Second, while introduced as a retired florist, Jack is actually an ex-C.I.A. operative, with all the tools of the agency at his disposal.
 The harder Greg tries, the more mistakes he makes, with Jack's elaborate security cameras catching every screw-up. Making matters even worse is the arrival of Pam's ex-boyfriend Kevin (Owen Wilson), a too-perfect-for-words gentleman who took up carpentry because he considers Jesus an excellent role model. Intimidated beyond belief, Greg finds himself the center of an escalating series of misadventures, beginning with the accidental destruction of a family urn and building to riotous extremes.
"Meet the Parents" has all the elements for a memorable farce and succeeds more often than not. Ben Stiller displays ace comic timing portraying a schnook floundering in the deep end of the societal pool. As the menacing straight man, Robert De Niro makes a great foil, looking far more comfortable here than he did in "Analyze This." Don't expect any surprises from either actor, though – both are playing variations of their standard personas. The only revelation comes from Owen Wilson ("Shanghai Noon"), who reinvents himself as a being of otherworldly nobility. Wilson is a true original, becoming more impressive with each new film.
Pity the women in the production, who are given little to work with. Blythe Danner does what she can with a sorely underwritten part, giving Dina a wry sparkle that shades her character in ways the script doesn't even hint at. As Pam, Teri Polo is simply there. There are no sparks between her and Stiller as she plays a girlfriend from the generic rack.
The flatness of the female characters is but one flaw in a screenplay that would have been well served by a rewrite or two. After a fairly taut beginning, "Meet the Parents" grows awfully sloppy in the middle, lobbing gags around with little style or grace. Director Jay Roach handles the material clumsily, focusing on large set pieces at the expense of smooth pacing or character development.
The best farces or comedies of manners flow like a mountain stream, with finely etched personalities shaping the direction and speed of the humor.  The film is undeniably funny, but with some finesse, it could have been so much better. Note to Jay Roach and company: Before you make your next movie, think things through, construct fully rounded characters and, for Pete's sake, watch a few episodes of "Frasier."
© 2000 Ed Johnson-Ott
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


This is not so much a trip report as a summary. I had planned on taking a journey today, perhaps sampling 5MeO-AMT for the first time. But as it was rather late I thought I'd wait and try for DPT later. Then the thought of a 2C-I experience came to me. Perfect!
I took 2400mg piracetam and then 25mg 2C-I half an hour later. It was the typical 2C-I trip, building up in periods of intensity and fading again. I spent a few hours listening to music and reflecting on my life. I then thought some 5MeO-DMT might add some insight. There is not much info regarding this combo, which is why I am writing this. I discovered several months ago the unique character of this combination, and vowed after that to use 5MeO-DMT only in conjunction with 2C-I. It might seem like an odd mix, but they actually blend very well indeed. Much different than my 2C-T-7/5MeO-DMT experience a few years ago.
So, I vaporised 10mg 5MeO-DMT and inhaled. This was not a planned experience, but just seemed what was required at the moment. It hit me very hard immedately. This experience was just as intense as my first encounter with 5MeO-DMT, but with much more personal meaning. As I lay there in a sort of limbo between life and death, I began to realize that I had to make a choice. To live or to die? No, I knew that I was not going to physically die. I soon began to understand that the choices we make are the single most defining element in determining our fates as individuals. This may seem simple on the surface, but choosing is much more than just saying so. It requires a commitment and dedication, an unbending intent to realize the maturity of those choices. Every movement we make should be done in full awareness and deliberateness.
Some time ago I had vowed to only take knowledge or information and never give. This was based more on a past personal relationship than anything. As I lay there wondering whether I should write all this up, I perceived that it would only be a self serving maneuver. But as I thought about it, I could perceive that choosing not to write this could be seen as equally self serving. I laughed at the paradox and decided to write this up just for the hell of it, for my own amusement:) If anybody else finds this usefull, so be it. This was not a waste of my time! Well, just another anecdote for the archives:)
Experience Reports are the writings and opinions of the individual authors who submit them.
Some of the activities described are dangerous and/or illegal and none are recommended by Erowid.


Clients
Here you will find a list of clients that we either have worked with in the past or that we are currently working with.
Mr. Deckert
Tim Meadows
Barbara Allen
Dunmore High School
Aaron Grandy
Larry Meyers
Blue Cross of Pennsylvania
Daniel Schofield
Prestige Postal Company
East Pennsylvania Seminary
Haymont Tires
Tract Industries
Stone & Son Suit Warehouse


webscene.when(function () { // set this property to display trees, buildings and other // 3D objects reflected in the water. view.environment.lighting.waterReflectionEnabled = true; }); /*********************************** * Add polygon layer with water body ***********************************/ const waterLayer = new FeatureLayer({ url: "https://services.arcgis.com/V6ZHFr6zdgNZuVG0/arcgis/rest/services/Water_bodies/FeatureServer", elevationInfo: { mode: "absolute-height", offset: 0 }, renderer: { type: "simple", symbol: { type: "polygon-3d", symbolLayers: [ { type: "water", waveDirection: 260, color: "#25427c", waveStrength: "moderate", waterbodySize: "medium" } ] } } });


Blueberries are perennial flowering plants with blue– or purple–colored berries. They are classified in the section Cyanococcus within the genus Vaccinium. Vaccinium also includes cranberries, bilberries, and huckleberries. Commercial "blueberries" – including both wild ('lowbush') and cultivated ('highbush') blueberries – are native to North America. The highbush blueberry varieties were introduced into Europe during the 1930s.
Blueberries are usually prostrate shrubs that can vary in size from 10 centimeters (3.9 in) to 4 meters (13 ft) in height. In commercial production of blueberries, the species with small, pea–size berries growing on low–level bushes are known as "lowbush blueberries" (synonymous with "wild"), while the species with larger berries growing on taller cultivated bushes are known as "highbush blueberries".
Price = {{ price | currency : "Rs."}}


1. Executive summary
We have not met in-person since the February 2020 meeting in Prague because of the global pandemic. We’re instead holding weekly teleconferences, as detailed in [P2145R1]. We focus on providing non-final guidance, and will use electronic straw polls as detailed in [P2195R0] to move papers and issues forward in a asynchronous manner.
Our main achievements have been:
-
Issue processing: most of the 50 language evolution issues have proposed resolutions.
-
C++23: we’ve started work on papers for C++23 and later.
-
Incubation: we’ve acted as EWG-I and "incubated" some early papers by providing early feedback to authors.
This paper outlines the work achieved, other ongoing work, and lists the straw polls that will be submitted for the February 2021 polling period.
2. Paper of note
-
[P1000R4] C++ IS schedule
-
[P0592R4] To boldly suggest an overall plan for C++23
-
[P1999R0] Process: double-check evolutionary material via a Tentatively Ready status
-
[P2195R0] Electronic Straw Polls
-
[P2145R1] Evolving C++ Remotely
3. Tentatively ready papers
Following our process in [P1999R0], we usually mark papers as tentatively ready for CWG. We would usually take a brief look at the next meeting, and if nothing particular concerns anyone, send them to CWG. However, given the pandemic, we’ve decided to provide guidance only in virtual teleconferences, and have an asynchronous polling mechanism to officially send papers to CWG or other groups as detailed in [P2195R0]. We will be polling to advance all of these papers in the February 2021 polling period, and therefore avoid listing them twice in this paper.
You can follow the lists of papers on GitHub:
4. Issue Processing
We’ve reviewed 50 Language Evolution issues at the Core groups' request, and have tentative resolutions for most. We don’t want to poll all of these at the same time, and will therefore only poll a subset in the February 2021 polling period, reserving other issues for later polling periods. We will therefore only poll the "tentatively ready" issues (since they’re tied to papers, and polled with said papers, as outlined below), as well as the "resolved" issues since telecon attendees believe that prior work has already addressed the issues.
§ 7 Remaining Open Issues contains a list of issues which aren’t being voted on in this polling period.
5. Polls
The current list of polls which EWG will take in the February 2021 polling period are:
5.1. P2223R1 Trimming whitespaces before line splicing
-
Not yet seen by WG14, nor the SG22 C / C++ liaison group.
-
Highlight: make trailing whitespaces after
\
non-significant. -
🗳 Poll: Forward P2223R1 "Trimming whitespaces before line splicing" to Core, thereby also fixing [CWG1698].
5.2. P2201R0 Mixed string literal concatenation
-
Seen by WG14 as [N2594], straw Poll: Does the committee wish to adopt N2594 into C23 as is? 18-0-2 passes.
-
Highlight: string concatenation involving string-literals with encoding-prefixes mixing
L
,"" u8
,"" u
, and"" U
is currently conditionally-supported with implementation-defined behavior, this paper makes it ill-formed."" -
🗳 Poll: Forward P2201R0 "Mixed string literal concatenation" to Core, after adding an Annex C entry.
5.3. P2186R1 Removing Garbage Collection Support
-
Highlight: remove (not deprecate) garbage collection support in C++23.
-
🗳 Poll: Forward P2186R1 "Removing Garbage Collection Support" to Core.
5.4. P2173R0 Attributes on Lambda-Expressions
-
Highlight: allow attributes for lambdas, those attributes appertaining to the function call operator of the lambda.
-
🗳 Poll: Forward P2173R0 "Attributes on Lambda-Expressions" to Core, thereby also fixing [CWG2097].
5.5. P2156R1 Allow Duplicate Attributes
-
Seen by WG14 as [N2557], straw Poll: Is the committee in favor of adopting N2557 into C23? 19-0-0 passes.
-
Highlight: current limitations on duplicate attributes are inconsistent, this change removes all limitations on duplicate attributes in an attribute-list for all attributes that specify a limitation. This affects
,carries_dependency
,deprecated
,fallthrough
,likely
,unlikely
,unused
, andnoreturn
.no_unique_address -
🗳 Poll: Forward P2156R1 "Allow Duplicate Attributes" to Core, thereby also fixing [CWG1914].
5.6. P2013R3 Freestanding Language: Optional :: operator new
-
Not yet seen by WG14, nor the SG22 C / C++ liaison group.
-
Highlight: on freestanding C++ implementations, make the various default allocating
optional. Placement:: operator new
is still required. Allnew
are still required. Hosted implementations are unchanged.:: operator delete -
🗳 Poll: Forward P2013R3 "Freestanding Language: Optional
" to Core.:: operator new
5.7. P1949R6 C++ Identifier Syntax using Unicode Standard Annex 31
-
C++20 NB comment NL029 05.10
-
Not yet seen by WG14, nor the SG22 C / C++ liaison group.
-
Highlight: C++11 uses a hand-curated list of Unicode codepoints to determine which characters are allowed in identifiers. This is flawed in many ways outlined in the paper. Replace this hand-curated list with the Unicode consortium’s recommendations for identifiers [UAX31].
-
🗳 Poll: Forward P1949R6 "C++ Identifier Syntax using Unicode Standard Annex 31" to Core.
5.8. P1938R2 if consteval
-
C++20 NB comment FR22 20.15.10, discussed in Belfast
-
Highlight: C++20 added
andstd :: is_constant_evaluated ()
, which interact poorly with each other. This paper adds a new form ofconsteval
statement to address the poor interaction.if -
🗳 Poll: Forward P1938R2 "
" to Core.if consteval
5.9. P1847R3 Make declaration order layout mandated
-
Highlight: C++ currently lets compilers reorder data member layout if they have different access controls. Compilers don’t take advantage of this permission. This paper removes the unused flexibility.
-
🗳 Poll: Forward P1847R3 "Make declaration order layout mandated" to Core.
5.10. P1401R4 Narrowing contextual conversions to bool
-
Addresses [CWG2320], which was caused by resolving [CWG2039], see Richard Smith’s email regarding this approach.
-
Highlight: allow conversions from integral types to type
inbool
andstatic_assert
-statements.if constexpr -
🗳 Poll: Forward P1401R4 "Narrowing contextual conversions to
" to Core.bool
5.11. P1393R0 A General Property Customization Mechanism
-
Highlight: "properties" are a customization mechanism at the center of [P0443R14] executors. The proposed approach is library-only, but it could be possible to develop a language-based approach instead. The discussion and poll’s goal are to avoid a late-changing redesign of executors based on wanting a language-based approach for customization.
-
🗳 Poll: We understand properties and think that specifying them purely in library is the right approach.
5.12. CWG2169 Narrowing conversions and overload resolution
- [CWG2169]
-
Current implementations ignore narrowing conversions during overload resolution, emitting a diagnostic if calling the selected function would involve narrowing. For example:
struct s { long m }; struct ss { short m ; }; void f ( ss ); void f ( s ); void g () { f ({ 1000000 }); // Ambiguous in spite of narrowing for f(ss) } However, the current wording of <IP_ADDRESS>.5 [over.ics.list] paragraph 7 says,
Otherwise, if the parameter has an aggregate type which can be initialized from the initializer list according to the rules for aggregate initialization (9.4.1 [dcl.init.aggr]), the implicit conversion sequence is a user-defined conversion sequence with the second standard conversion sequence an identity conversion.
In the example above,
cannot be initialized fromss
because of the narrowing conversion, so presumably{ 1000000 }
should not be considered. If this is not the intended outcome, paragraph 7 should be restated in terms of having an implicit conversion sequence, as in, e.g., bullet 9.1, instead of a valid initialization.f ( ss ) - Notes 2020-04-29
- JF’s email to EWG 2020-10-19, with the follow-up suggestion that no paper was needed and CWG could resolve the issue if given guidance from EWG.
- 🗳 Poll: Guidance to Core: implementations are right, the Standard needs to be fixed to address this issue by following existing implementations.
5.13. CWG2355 Deducing noexcept-specifiers
-
The list of deducible forms in <IP_ADDRESS> [temp.deduct.type] paragraph 8 does not include the ability to deduce the value of the constant in a noexcept-specifier, although implementations appear to allow it. Note: multiple standard library implementations rely on it.
-
🗳 Poll: Guidance to Core: modify the Standard such that the value of a constant in a noexcept-specifier can be deduced.
5.14. CWG476 Determining the buffer size for placement new
-
Resolved by [CWG2382] (no overhead for placement
for arrays). CWG2382 was moved in Belfast as part of [P1969r0].new -
🗳 Poll: Mark CWG476 "Determining the buffer size for placement
" as resolved by P1969r0, and a duplicate of CWG2382.new
5.15. CWG687 template
keyword with unqualified-ids
-
Resolved by [P0846r0]
-
🗳 Poll: Mark CWG687 "
keyword with unqualified-ids" as resolved by P0846r0.template
5.16. CWG1326 Deducing an array bound from an initializer-list
-
Resolved by [P0127R2] Declaring non-type
parameters withtemplate
, and [CWG1591].auto -
🗳 Poll: Mark CWG1326 "Deducing an array bound from an initializer-list" as resolved by P0127R2, and a duplicate of CWG1591.
5.17. CWG1331 const
mismatch with defaulted copy constructor
-
Resolved by [P0641r2] (whose title is Resolving Core Issue #1331, also resolves [CWG1426]).
-
🗳 Poll: Mark CWG1331 "
mismatch with defaulted copy constructor" as resolved by P0641r2.const
5.18. CWG1393 Pack expansions in using-declarations
-
Resolved by [P0195r2] (same title as issue)
-
🗳 Poll: Mark CWG1393 "Pack expansions in using-declarations" as resolved by P0195r2.
5.19. CWG1426 Allowing additional parameter types in defaulted functions
-
🗳 Poll: Mark CWG1426 "Allowing additional parameter types in defaulted functions" as resolved by P0641r2.
5.20. CWG1561 Aggregates with empty base classes
-
Resolved by [P0017r1] (which allowed aggregates to have base classes)
-
🗳 Poll: Mark CWG1561 "Aggregates with empty base classes" as resolved by P0017r1.
5.21. CWG1912 exception-specification of defaulted function
-
The current rules requiring a defaulted member function to have an exception-specification compatible with that of the implicitly-declared function are overly constraining. It should be possible, for example, to specify that a defaulted move constructor will be non-throwing, based on knowledge available to the programmer, even if the implicitly-declared constructor would be throwing.
-
Resolved by [p1286r2]
-
🗳 Poll: Mark CWG1912 "exception-specification of defaulted function" as resolved by p1286r2.
5.22. CWG1931 Default-constructible and copy-assignable closure types
-
Resolved by [P0624r2] Default constructible and assignable stateless lambdas
-
🗳 Poll: Mark CWG1931 "Default-constructible and copy-assignable closure types" as resolved by P0624r2.
5.23. CWG2295 Aggregates with deleted defaulted constructors
-
Should a class with a deleted non-user-provided default constructor be considered an aggregate?
-
Resolved by [P1008r1] Prohibit aggregates with user-declared constructors
-
🗳 Poll: Mark CWG2295 "Aggregates with deleted defaulted constructors" as resolved by P1008r1.
5.24. CWG2341 Structured bindings with static
storage duration
-
Resolved by [P1091r3] Extending structured bindings to be more like variable declarations
-
🗳 Poll: Mark CWG2341 "Structured bindings with
storage duration" as resolved by P1091r3.static
5.25. CWG2343 void *
non-type template parameters
-
According to 13.2 [temp.param] bullet 4.2, non-type template parameters of pointer type must be either pointer to object or pointer to function. This excludes
, which is an object pointer but not a pointer to object. However, most or all current implementations acceptvoid *
as a non-type template parameter. Notes from the April, 2018 Core teleconference: Not all implementations accept avoid *
template parameter, so this should not be a DR if it is eventually adopted. Furthermore, there is some implementation divergence over the kinds of template arguments that can be passed to avoid *
template parameter.void * -
Resolved by [P0732R2] (which used
in defining strong structural equality and used that for NTTPs) because [P0515R3] had givenstd :: strong_ordering
the type<=>
for "object pointers" (which includesstd :: strong_ordering
, even though void is not an object type). Later [P1907R1] replaced all that, saying simply that structural types (which include all scalar types) were acceptable, but that didn’t changevoid *
's status. Davis emailed EWG the above text.void * -
🗳 Poll: Mark CWG2343 "
non-type template parameters" as resolved by P0732R2.void *
5.26. CWG??? unqualified lookup in conversion-type-ids (Sent by Richard Smith to EWG, from CWG)
-
The basic situation looks like this:
struct A { struct B {}; operator B (); }; void f ( A a ) { a . operator B (); } There is a special-case lookup rule that allows this code to work: when looking up the
inB
, we look insidea . operator B ()
. Presumably the intent is to allowa
to be named in the same way when it’s referenced as it was named when it was declared. This is a fairly general rule: inoperator B
, we look up the< some context > operator B
in the same place in which we later look up the nameB
.operator B Question The issue we are facing is: exactly what lookups does the special-case rule apply to? Consider a few examples:
a . operator B < C > (); a . operator B D ::* (); a . operator decltype ( E )(); Which of
,B
,C
, andD
get the special "look this name up inE
" rule?a There is implementation divergence:
- Clang says none.
- EDG and MSVC say
only.B - GCC says
andB
.D - And the consistent rules we’re looking at now would say all of
,B
,C
, andD
are looked up inE
.A
- Resolved by [P1787R6].
- Notes 2020-10-28
- 🗳 Poll: Mark the CWG issue sent by Richard Smith to EWG on 2020-06 "unqualified lookup in conversion-type-ids" as resolved by P1787R6.
For each poll, you will be asked to vote one of:
-
Strongly in favor
-
In favor
-
Neutral
-
Against
-
Strongly against
You will also have the option to abstain from voting on a particular poll. You will be asked to comment on each poll. This comment is mandatory, as it helps the chair determine consensus.
6. Teleconferences
Here are the minutes for the virtual discussions that were held since the Prague meeting in February 2020:
- 2020-04-09 Issue Processing
- 2020-04-15 Issue Processing
- 2020-04-23 Issue Processing
- 2020-04-29 Issue Processing
- 2020-05-07 Issue Processing
- 2020-05-13 Issue Processing
- 2020-05-21 A General Property Customization Mechanism—[P1393R0] (P1393 tracking issue)
- 2020-06-10 Reviewing Deprecated Facilities of C++20 for C++23—[P2139R1] (P2139 tracking issue)
- 2020-06-18 C++ Identifier Syntax using Unicode Standard Annex 31—[P1949R4] (P1949 tracking issue)
- 2020-06-24 Extended floating-point types and standard names—[P1467R4] (P1467 tracking issue)
- 2020-07-02 Allow Duplicate Attributes, Attributes on Lambda-Expressions—[P2156R0] (P2156 tracking issue) and [P2173R0] (P2173 tracking issue)
- 2020-07-08 Pointer lifetime-end zap and provenance, too—[P1726R3] (P1726 tracking issue)
- 2020-07-16 Guaranteed copy elision for return variables—[P2025R1] (P2025 tracking issue)
- 2020-07-30 Reviewing Deprecated Facilities of C++20 for C++23, Removing Garbage Collection Support—[P2139R2] (P2139 tracking issue) and [P2186R0] (P2186 tracking issue)
- 2020-08-05 Transactional Memory Lite Support in C++—[P1875R0] (P1875 tracking issue)
- 2020-08-19 Freestanding Language: Optional
, Mixed string literal concatenation—[P2013R2] (P2013 tracking issue) and [P2201R0] (P2201 tracking issue):: operator new - 2020-08-27 Exhaustiveness Checking for Pattern Matching—[P1371R3] (P1371 tracking issue)
- 2020-09-02
- a simple, scannable preprocessor-based resource acquisition method—[P1967R2] (P1967 tracking issue)#embed - 2020-09-10 A pipeline-rewrite operator—[P2011R1] (P2011 tracking issue)
- 2020-09-16 Pattern matching: inspect is always an expression—[P1371R3] (P1371 tracking issue)
- 2020-09-24 C++ Identifier Syntax using Unicode Standard Annex 31, Member Templates for Local Classes—[P1949R6] (P1949 tracking issue) and [P2044R0] (P2044 tracking issue)
- 2020-09-30 Narrowing contextual conversions to bool, Generalized pack declaration and usage—[P1401R3] (P1401 tracking issue) and [P1858R2] (P1858 tracking issue)
- 2020-10-08 Compound Literals,
—[P2174R0] (P2174 tracking issue) and [P1938R1] (P1938 tracking issue)if consteval - 2020-10-14 Inline Namespaces: Fragility Bites, Trimming whitespaces before line splicing—[P1701R1] (P1701 tracking issue) and [P2223R0] (P2223 tracking issue)
- 2020-10-22 Issues Processing
- 2020-10-28 Issues Processing
- 2020-11-05 Deducing
—P0847R5 (P0847 tracking issue)this - 2020-11-19
in pattern matchinggoto - 2020-12-03
: decay-copy in the language—P0849R5 (P0849 tracking issue)auto ( x ) - 2021-01-14 Polls
7. Remaining Open Issues
The following table lists all remaining open issues referred to EWG by Core or Library. Some of them are ready to be polled but are held back from the February 2021 polling period to limit the number of polls in this round.
|
From |
# |
Title |
Notes |
Resolution |
|
Core |
Explicit instantiation of in-class |
A Note 2020-04-29 Tentative agreement: This should be well-formed. SF 1 F 10 N 2 A 1 SA 0 JF emailed EWG / Core about this. Davis: the current name lookup approach which Core is taking in p1787 would disallow this. Supporting this is possible, it would be inconsistent, but would also be a feature. Notes 2020-10-22: wait until p1787 is voted into the working draft, because it’s making this behavior intentional. At that point, we can vote on marking the issue as Not a Defect. No objection to unanimous consent. |
♻ | |
|
Core |
Non- |
[Detailed description pending.] Hubert: question over the role of the For A user’s desire for wanting to suppress implicit instantiation can arise for different reasons: To reduce space in object files, executables, etc. and similarly to reduce the number of input symbols to the linker To reduce compile time in performing semantic analysis for instantiations whose definitions are provided elsewhere To control point-of-instantiation, avoiding contexts where the requisite declarations are not declared The special rule around inline functions allows Consider the following as a translation unit:
Marking the template definition The issue initially points out that this use of the I am not sure if CWG is asking EWG a specific question other than the general "we do not believe this is a wording or obvious consistency issue; is this an issue in terms of design?" Meeting: Hubert forked the thread on the reflector. Might want the education SG to take a look, or might want a paper. Meeting 2020-10-28: Inbal will try to put together the wording, to prove / disprove whether this is a defect. |
♻ | |
|
Lib |
initializer_list assignability |
std::initializer_list::operator= [support.initlist] is horribly broken and it needs deprecation: std::initializer_list<foo> a = {{1}, {2}, {3}}; a = {{4}, {5}, {6}}; // New sequence is already destroyed. Assignability of initializer_list isn’t explicitly specified, but most implementations supply a default assignment operator. I’m not sure what [description] says, but it probably doesn’t matter. Proposed resolution: Edit [support.initlist] p1, class template initializer_list synopsis, as indicated: namespace std { template<class E> class initializer_list { public: […] constexpr initializer_list() noexcept; initializer_list(const initializer_list&) = default; initializer_list(initializer_list&&) = default; initializer_list& operator=(const initializer_list&) = delete; initializer_list& operator=(initializer_list&&) = delete; constexpr size_t size() const noexcept; […] }; […] } LWG telecon appears to want a language change to disallow assigning a braced-init-list to an std::initializer_list but still permit move assignment of std::initializer_list objects. That is, auto il1 = {1,2,3}; auto il2 = {4,5,6}; il1 = {7,8,9}; // currently well-formed but dangles immediately; should be ill-formed il1 = std::move(il2); // currently well-formed and should remain so Meeting: Proposed resolution:
SF F N A SA 0 3 12 0 0 JF emailed LEWG, to see if they have an opinion, no feedback. Asked LEWG chairs to schedule for a telecon. LWG discussed priority. |
♻ | |
|
Lib |
std::function should not return dangling references |
If a std::function has a reference as a return type, and that reference binds to a prvalue returned by the callable that it wraps, then the reference is always dangling. Because any use of such a reference results in undefined behaviour, the std::function should not be allowed to be initialized with such a callable. Instead, the program should be ill-formed. A minimal example of well-formed code under the current standard that exhibits this issue: int main() { std::function<const int&()> F([]{ return 42; }); int x = F(); // oops! } Proposed resolution: Add a second paragraph to the remarks section of <IP_ADDRESS>.1 [func.wrap.func.con]: template<class F> function(F f); -7- Requires: F shall be CopyConstructible. -8- Remarks: This constructor template shall not participate in overload resolution unless
[…] Tim: LWG in Batavia 2018 would like a way to detect when the initialization of a reference would bind it to a temporary. This requires compiler support, since there’s no known way in the current language to do so reliably in the presence of user-defined conversions (see thread starting at https://lists.isocpp.org/lib/2017/07/3256.php). Meeting: Tim wrote p2255 to address this. Ville thinks there should be an analysis of alternative approaches. Also see P0932. |
♻ | |
|
Core |
Restrictions on local classes |
Now that the restriction against local classes being used as template arguments has been lifted, they are more useful, yet they are still crippled. For some reason or oversight, the restriction against local classes being templates or having member templates was not lifted. Allowing local classes to have member templates facilitates generic programming (the reason for lifting the other restriction), especially when it comes to the visitor-pattern (see the boost::variant documentation and the following example) as implemented in boost and the boost::MPL library (since functors have to be template classes in mpl, and higher-order functors have to have member templates to be useful). A local class with a member template would allow this desirable solution: #include <boost/variant.hpp> int main() { struct times_two_generic: public boost::static_visitor<> { template <typename T> void operator()(T& operand) const { operand += operand; } }; std::vector<boost::variant<int, std::string>> vec; vec.push_back(21); vec.push_back("hello "); times_two_generic visitor; std::for_each(vec.begin(), vec.end(), boost::apply_visitor(visitor)); } Is there any compelling reason not to allow this code? Is there any compelling reason not to allow local classes to be templates, have friends, or be able to define their static data members at function scope? Wouldn’t this symmetry amongst local and non-local classes make the language more appealing and less embarrassing? Also see p2044, seen by EWGI in Prague and requested to be merged with P1988, and implementors queried. The current paper draft addresses all of this. Meeting: (notes) Some folks unsure that we should do anything here. Revisit the resolution with P2044. Extension issues are a closed status on the issues list, like NAD Future was for LWG I find it helpful to have a status that says EWG may still be considering it. Suggest closing as Not A Defect because we have significant implementation concerns, but we’ll explore the design space in P2044. All in favor. |
NAD | |
|
Core |
Base-derived conversion in member type of pointer-to-member conversion |
Related to CWG 170, drafting by Clark seems unlikely. This is section 2.1 of Jeff Snyder’s P0149R0, which was approved by EWG, 4 years ago, waiting for wording. JF reached out to Jeff. Did wording with Jens, main blocker is lack of implementation. Meeting: (notes) Suggest closing as Not A Defect because we have implementation uncertainties, but we’ll explore the design space in P0149. ABI group will discuss. All in favor. |
NAD | |
|
Core |
Lifetime of temporaries in range-based for |
// some function std::vector<int> foo(); // correct usage auto v = foo(); for( auto i : reverse(v) ) { std::cout << i << std::endl; } // problematic usage for( auto i : reverse(foo()) ) { std::cout << i << std::endl; } Meeting: (notes, also discussed in Rapperswil 2014) Suggest closing as Not A Defect because it’s a change which might have effects on existing code (might cause bugs), and might need to change more than just range-based loops. See p0614, p0577, p0936, p1179. We’ll explore the design space in a separate paper, Herb circled back with Nico on this, might write a paper. All in favor. |
NAD | |
|
Core |
reinterpret_cast for all types with the same size and alignment |
During the discussion of issue 799, which specified the result of using reinterpret_cast to convert an operand to its own type, it was observed that it is probably reasonable to allow reinterpret_cast between any two types that have the same size and alignment. Additional note, April, 2015: It has been suggested that this question may more properly be the province of EWG, especially in light of discussions during the resolution of issue 330. The priority has been deleted to allow CWG to reconsider its status. Rationale (May, 2015): CWG agreed that this question should be considered from a language design perspective and is thus being referred to EWG. Suggest rejection: we chose to add std::bit_cast to provide exactly this functionality instead of extending reinterpret_cast. Meeting: (notes) Suggest closing as Not A Defect. bit_cast addresses some of the usecases this issue might cover. We’d want separate papers to support other usescases, but have nothing outstanding at the moment. All in favor. |
NAD | |
|
Core |
Querying the alignment of an object |
Quick example using ‘auto’ illustrates why we might want this capability for objects as well as types. Principle of least astonishment suggests it is surprising for sizeof and alignof to behave differently in this regard. Recommend shipping this straight to core as soon as we can find a wording champion. We need to discuss with WG14. Questions for EWG to answer before forwarding:
This needs a design paper rather than going straight to core. https://godbolt.org/z/TeVA9T GCC seems to report the alignment of the object not just of decltype(object). Meeting: (notes, also discussed in Rapperswil 2014) Suggest closing as Not A Defect, the design is complex especially around alignment of object versus type. Invite a paper, Inbal will pitch in, Alidair can collaborate. All in favor. Inbal’s paper: P2152R0 |
NAD | |
|
Core |
Explicit specializations in non-containing namespaces |
The current wording of <IP_ADDRESS> [namespace.memdef] and 13.9.3 [temp.expl.spec] requires that an explicit specialization be declared either in the same namespace as the template or in an enclosing namespace. It would be convenient to relax that requirement and allow the specialization to be declared in a non-enclosing namespace to which one or more if the template arguments belongs. Additional note, April, 2015: See EWG issue 48. Might allow us to revert DR2061 and all the horribleness that created and described in p1701. The problem 1077 addresses is the motivating factor in dr2061. Also see CWG 2370. Meeting: (notes) Suggest closing as Not A Defect. See p0665, minutes. Continue under p0665 or a forked version of it. All in favor. |
NAD | |
|
Core |
trailing-return-type and point of declaration |
template <class T> T list(T x); template <class H, class ...T> auto list(H h, T ...args) -> decltype(list(args...)); // list isn’t in scope in its own trailing-return-type auto list3 = list(1, 2, 3); Meeting: (notes, also discussed in Rapperswil 2014) there might be compiler divergence according to Daveed. Suggest closing as Not A Defect, it would be tricky to change behavior without ambiguity. "Fixing" this would break existing code that relies on seeing only previous declarations. No objection to unanimous consent. |
NAD | |
|
Core |
Objects with no linkage in non-type template arguments |
According to 13.4.2 [temp.arg.nontype] paragraph 1 bullet 3, only objects with linkage can be used to form non-type template arguments. Is this restriction still needed? It would be convenient to use block-scope objects as template arguments. Resolved by N4268. The following is valid: template <int *> struct A; auto f() { static int x; A<&x> *ap = nullptr; return ap; } There is no longer any linkage restriction. There is a restriction on storage duration, which seems reasonable (you can use the address of a local static variable but not of a local automatic variable as a non-type template argument). Meeting: (notes, also discussed in Rapperswil 2014) Suggest closing as Not A Defect. Addressed by N4268. No objection to unanimous consent. |
NAD | |
|
Core |
Omitted bound in array new-expression |
The syntax for noptr-new-declarator in <IP_ADDRESS> [expr.new] paragraph 1 requires an expression, even though the bound could be inferred from a braced-init-list initializer. It is not clear whether 9.4.1 [dcl.init.aggr] paragraph 4, An array of unknown size initialized with a brace-enclosed initializer-list containing n initializer-clauses, where n shall be greater than zero, is defined as having n elements (<IP_ADDRESS> [dcl.array]). should be considered to apply to the new-type-id variant, e.g., new (int[]){1, 2, 3} This was addressed by p1009 Meeting: (notes) Suggest closing as Not A Defect. Addressed by P1009. No objection to unanimous consent. |
NAD | |
|
Core |
Language linkage and function type compatibility |
Currently function types with different language linkage are not compatible, and <IP_ADDRESS> [expr.call] paragraph 1 makes it undefined behavior to call a function via a type with a different language linkage. These features are generally not enforced by most current implementations (although some do) between functions with C and C++ language linkage. Should these restrictions be relaxed, perhaps as conditionally-supported behavior? Somewhat related to CWG1463. Meeting: (notes) no strong consensus at the moment, Erich Keane brought this up with SG12 Undefined Behavior. Long discussion, will need to revisit, need a paper. Meeting Oct 22nd 2020: will need a volunteer to write a paper, but the wording in the standard is unambiguous, and we have existence proof of platforms which use different calling conventions between C and C++. However many major compilers have chosen to ignore this. Not a defect, but we welcome a paper to change the status quo. No objection to unanimous consent. |
NAD | |
|
Core |
Default arguments for template parameter packs |
Although 13.2 [temp.param] paragraph 9 forbids default arguments for template parameter packs, allowing them would make some program patterns easier to write. Should this restriction be removed? Meeting: (notes) Suggest closing as Not A Defect. Interesting design space, but needs a paper, see N3416. No objection to unanimous consent. |
NAD | |
|
Core |
List-initialization of array objects |
The resolution of issue 1467 now allows for initialization of aggregate classes from an object of the same type. Similar treatment should be afforded to array aggregates. See recent discussion on allowing 'auto x[] = {1, 2, 3};' -- this topic came up there. The two questions can be answered independently, but some consider them to be related. Meeting: (notes) Suggest closing as Not A Defect. Fixing anything in this space would require a paper which considers the entire design space, Timur might be interested in this. No objection to unanimous consent. |
NAD | |
|
Core |
Non-identifier characters in ud-suffix |
JF forwarded to SG16 Unicode given their work on TR31. Tracked on GitHub. SG16 reviewed D1949R3, still needs wording changes. Discussed at the April 22nd SG16 telecon. SG16 Poll: Is there any objection to unanimous consent for recommending rejection of this proposal? No objection to unanimous consent. EWG Meeting: (notes 2020-04-15, notes 2020-05-07) Suggest closing as Not A Defect. No objection to unanimous consent. |
NAD | |
|
Core |
Preventing explicit specialization |
A desire has been expressed for a mechanism to prevent explicitly specializing a given class template, in particular std::initializer_list and perhaps some others in the standard library. It is not clear whether simply adding a prohibition to the description of the templates in the library clauses would be sufficient or whether a core language mechanism is required. Meeting: (notes) Suggest closing as Not A Defect. No objection to unanimous consent. This could be a language feature, would need library usecase examples. Poll: we are interested in such a paper SF 2 F 13 N 6 A 1 SA 0 |
NAD | |
|
Core |
Potentially-invoked destructors in non-throwing constructors |
Since the base class constructor is non-throwing, the deleted base class destructor need not be referenced. There’s a typo in the issues list here: it should say "Since the derived class constructor is non-throwing, the deleted base class destructor need not be referenced." Meeting: (notes 2020-04-23) the proposed wording changes the implementation leeway in two-phase unwinding, which breaks some existing ABIs. We would need a paper to explore this further. Suggest closing as Not A Defect. No objection to unanimous consent. |
NAD | |
|
Core |
Lvalues of type void |
There does not seem to be any significant technical obstacle to allowing a void* pointer to be dereferenced, and that would avoid having to use weighty circumlocutions when casting to a reference to an object designated by such a pointer. Might consider this a duplicate of the discussion on "regular void". JF reached out to Matt. He has an implementation in clang. Needs to update the paper. Might need a volunteer to present. Daveed would be interested in presenting. Meeting: (notes 2020-04-23) Suggest closing as Not A Defect. Explore under the “regular void” umbrella. No objection to unanimous consent. |
NAD | |
|
Core |
Relaxing exception-specification compatibility requirements |
According to 14.5 [except.spec] paragraph 4, If any declaration of a function has an exception-specification that is not a noexcept-specification allowing all exceptions, all declarations, including the definition and any explicit specialization, of that function shall have a compatible exception-specification. This seems excessive for explicit specializations, considering that paragraph 6 applies a looser requirement for virtual functions: If a virtual function has an exception-specification, all declarations, including the definition, of any function that overrides that virtual function in any derived class shall only allow exceptions that are allowed by the exception-specification of the base class virtual function. The rule in paragraph 3 is also problematic in regard to explicit specializations of destructors and defaulted special member functions, as the implicit exception-specification of the template member function cannot be determined. There is also a related problem with defaulted special member functions and exception-specifications. According to 9.5.2 [dcl.fct.def.default] paragraph 3, If a function that is explicitly defaulted has an explicit exception-specification that is not compatible (14.5 [except.spec]) with the exception-specification on the implicit declaration, then
This rule precludes defaulting a virtual base class destructor or copy/move functions if the derived class function will throw an exception not allowed by the implicit base class member function. Meeting: (notes 2020-04-23) JF will work with Mike to update wording to C++20. Will revisit. From Mike: This issue is NAD since we eliminated typed exception-specifications. The current wording, dealing only with noexcept(true) and noexcept(false), does not have this issue. Will remove “extension” status. Meeting: no objection to CWG taking it back, and marking it as NAD. |
NAD | |
|
Core |
decltype(auto) with direct-list-initialization |
Paper N3922 changed the rules for deduction from a braced-init-list containing a single expression in a direct-initialization context. Should a corresponding change be made for decltype(auto)? E.g., auto x8a = { 1 }; // decltype(x8a) is std::initializer_list<int> decltype(auto) x8d = { 1 }; // ill-formed, a braced-init-list is not an expression auto x9a{ 1 }; // decltype(x9a) is int decltype(auto) x9d{ 1 }; // decltype(x9d) is int See also issue 1467, which also effectively ignores braces around a single expression, this change would be parallel to that one, even though the primary motivation for delctype(auto) is in the return type of a forwarding function, where direct-initialization does not apply. Meeting: (notes 2020-04-23) Suggest closing as Not A Defect. This would be a language change, it’s unclear that we want to make such a change. It would require a paper. Mike Spertus is writing a paper with some overlap, will cover this as well. No objection to unanimous consent. |
NAD | |
|
Core |
Array temporaries in reference binding |
The current wording of the Standard appears to permit code like
creating a temporary array of ten elements and binding the parameter reference to it. This is controversial and should be reconsidered. (See issues 1058 and 1232.) Meeting: (notes 2020-04-23) JF digging more, talking to Richard about this. Somewhat related to P2174 compound literals. Would be very strange if ... were invalid but ... ... were both OK. Maybe either we should allow the trailing elements to be zeroed in general (the status quo), or not (a major breaking change). Which means we should reject the issue on consistency grounds. The general rule is that if T &&r = init; ... can’t bind directly, we create a temporary initialized as if with T r = init; ... and bind to that. (And similarly for const references.) Another question: Do we want to support (T){inits} as a synonym for T{inits}? Meeting Oct 22nd 2020: Note that the issue itself is defective, and CWG2352 references p1358, and was resolved, leading us to believe that this is now mainstream and not controversial. Not a defect. No objection to unanimous consent. |
NAD | |
|
Core |
Copy elision and comma operator |
Currently, _N4750_.15.8 [class.copy] paragraphs 31-32 apply only to the name of a local variable in determining whether a return expression is a candidate for copy elision or move construction. Would it make sense to extend that to include the right operand of a comma operator? X f() { X x; return (0, x); } Meeting: (notes 2020-04-23) Consider expanding to other places that expand bit-field-ness such as return b ? throw : x;. Suggest closing as Not A Defect. Will need a paper to address, no current volunteer for this. No objection to unanimous consent. |
NAD | |
|
Core |
Deprecated default generated copy constructors |
EWG has indicated that they are not currently in favor of removing the implicitly declared defaulted copy constructors and assignment operators that are eprecated in _N4750_.15.8 [class.copy] paragraphs 7 and 18. Should this deprecation be removed? Related: discussing under p2139 deprecations. Meeting: (note 2020-04-29) Suggest closing as Not A Defect. No objection to unanimous consent. We either want to remove entirely, or un-deprecate. This will need a paper, Ville will talk with Alisdair about forking the topic from p2139. |
NAD | |
|
Core |
Value-initialization of array types |
Although value-initialization is defined for array types and the () initializer is permitted in a mem-initializer naming an array member of a class, the syntax T() (where is an array type) is explicitly forbidden by <IP_ADDRESS> [expr.type.conv] paragraph 2. This is inconsistent and the syntax should be permitted. Rationale (July, 2009): The CWG was not convinced of the utility of this extension, especially in light of questions about handling the lifetime of temporary arrays. This suggestion needs a proposal and analysis by the EWG before it can be considered by the CWG. This has become a more severe inconsistency after we adopted Ville’s P0960 for C++20. Now it’s not only () that has this weird special-case restriction, it’s (a, b, c) too: using X = int[]; X x{1, 2, 3}; // ok, int[3] X y(1, 2, 3); // ok, int[3] f(X{1, 2, 3}); // ok, int[3] temporary f(X(1, 2, 3)); // error Meeting: (notes) it is a defect, need a paper. David Stone trying to find a volunteer to write said paper. All in favor. |
Paper needed | |
|
Core |
extern "C" alias templates |
Currently 13 [temp] paragraph 4 forbids any template from having C linkage. Should alias templates be exempt from this prohibition, since they do not have any linkage? Additional note, April, 2013: It was suggested (see messages 23364 through 23367) that relaxing this restriction for alias templates could provide a way of addressing the long-standing lack of a way of specifying a language linkage for a dependent function type (see issue 13). The priority was deleted to allow CWG to consider the implications of that potential application of the facility. We should either have some way to express a dependent function type with C language linkage (and should accept 1555 below) or we should remove the notion that C language linkage (or not) is part of the function type at all. (Apparently some targets used it; are they still in use? EDG probably knows.) Actively discussed on CWG reflector. Davis’ interpretation of CWG discussion: I don’t speak for Core, of course, but my (Evolutionary) thoughts are those given (last) in the message to which you replied: neither the wording nor the apparent intent of [temp.pre]/6’s restrictions on C linkage for templates make any sense. Since templates (and explicit specializations) can’t have C linkage of the name-mangling variety (which the standard calls language linkage of a (function) name) but can have C linkage of the calling-convention variety (which the standard calls language linkage of a (function) type), extern "C" should grant them the latter and not the former with no error. This has certain obvious applications involving C APIs with callbacks. (Put differently, CWG13 shouldn’t have been rejected; it appears to have gotten bogged down in questions of syntax, but we have an adequate syntactic workaround that we merely have to permit.) CWG1463 asks for a (very) proper subset of the above: merely that extern "C" be allowed to apply to alias templates (claiming incorrectly that they have no name with linkage at all). I consider it more relevant (and more productive) to talk about whether entities have names with language linkage than with the ordinary kind. The Core reflector discussion (which seems to have finished for the moment) also touched on the case where "the same" function template is declared with two different language linkages for its type, but the only relevant Evolution input there would be a decision to go the opposite way and forbid function templates from having types with C language linkage entirely. (They currently can, but it’s mostly or entirely useless.) If (for CWG1555, also on your list) the rules about language linkage of (function) types are sufficiently relaxed, then CWG1463 may be moot (and my extension of it with it), but that seems unlikely given Hubert’s recent identification of a case where they matter. Meeting: (notes 2020-04-15, notes 2020-10-22, also discussed in Rapperswil 2014) We agree that this is an issue. extern “C” on a template should only affect calling convention, and not the mangling. Davis and Hubert volunteer to write a paper. Unanimous consent. |
Paper needed | |
|
Core |
Ellipsis following function parameter pack |
Although the current wording permits an ellipsis to immediately follow a function parameter pack, it is not clear that the <cstdarg> facilities permit access to the ellipsis arguments. The problem here (which is not explained in the issue) is: how do you supply the name of the last parameter before the ellipsis to va_start? You can’t put the name of a pack there (it wouldn’t be expanded) and there’s no way to name the last element of the pack (nor to deal with the case where the pack is empty). Meeting: (notes) 3 options: fix wording around “last parameter”, remove facility entirely (either va_start or function declarator), try to invent a language facility. JF emailed EWG to see if anyone has a strong preference, or if we should send back to CWG to fix wording, long discussion. Michael Spertus: I am willing to commit to including and analysis on this in an upcoming paper on parameter packs. JF followed up with Michael and Barry, no response. |
Paper needed | |
|
Core |
Type of __func__ |
Two questions have arisen regarding the treatment of the type of the __func__ built-in variable. First, some implementations accept void f() { typedef decltype(__func__) T; T x = __func__; } even though T is specified to be an array type. In a related question, it was noted that __func__ is implicitly required to be unique in each function, and that not only the value but the type of __func__ are implementation-defined; e.g., in something like inline auto f() { return &__func__; } the function type is implementation-specific. These concerns could be addressed by making the value a prvalue of type const char* instead of an array lvalue. Rationale (November, 2018): See also issue 2362, which asks for the ability to use __func__ in a constexpr function. These two goals are incompatible. The deep question here is about __func__ and the ODR. Does EWG want implementations to somehow behave as if __func__ is the same in all copies of an inline function (in which case it can have an array type and be usable in constant expressions, but the demangling algorithm used to construct it becomes part of the ABI), or does EWG want implementations to behave as if __func__ may differ between copies, so is in effect not known until runtime (in which case it must have either pointer or incomplete array type, and its value is not usable in constant expressions -- but its address could still be usable). Note: C++20 has std::source_location::function_name. Meeting: (notes 2020-04-23) We should discuss this with WG14. This is indeed a language issue. No objection to unanimous consent. We’ll need a paper, potentially considering what Reflection could do, JF brought it up on the mailing list. We probably need a paper to disentangle this. |
Paper needed | |
|
Core |
Ambiguity resolution for cast to function type |
C++ has a blanket disambiguation rule that says if a sequence of tokens can be interpreted as either a type-name or an expression, the type-name interpretation is chosen. This is unhelpful in cases like (T())+3 where the current rules make "(T())" a cast to the type "function with no parameters returning T" rather than a parenthesized value-initialization of a temporary of type T. The former interpretation is always ill-formed - you can’t cast to a function type - while the latter could be useful. Richard’s proposed resolution, cited above, is to avoid the ambiguity by changing the grammar so that cases like "(T())" cannot be parsed as a cast. The wording in the proposal applies that change to a number of different contexts where the ambiguity can come into play. There are two contexts where the change is _not_ applied, however: 1) the operand of typeid, and 2) a template-argument. During our discussion yesterday, there was some support for the idea of applying the change to typeid, as well, although that would be a breaking change for any programs that rely on the current disambiguation to get type information for such function types. There was general agreement, however, to exclude template arguments, since they are used for things like std::function. CWG would, therefore, like some guidance from EWG on two questions. First, should we apply the new syntax to the operand of typeid, even though it’s a breaking change? More generally, the question was raised whether we should make this change at all. Although resolving the ambiguity in the other direction would arguably be more convenient in many cases, there is a tension between that convenience and the complexity of the language. In particular, we would be creating a situation where the exact same sequence of tokens would mean two different things, depending on the context in which they appear. Is the convenience worth the cost in complexity? Meeting: (note 2020-04-29, notes 2020-03-23, note from Core summer 2020, notes from Core Prague 2020, notes from Core 2019-01-07, notes from Core Kona 2019, notes from Core Cologne 2019) This is an issue, we’d like to change the standard to resolve it: SF 0 F 6 N 4 A 3 SA 2 Davis emailed EWG reflector. Long discussion. |
Paper needed | |
|
Core |
Are default argument instantiation failures in the “immediate context”? |
Example 1: template <typename T, typename U = T> void fun(T v, U u = U()) {} void fun(...) {} struct X { X(int) {} // no default ctor }; int main() { fun (X(1)); } Consider the following example (taken from issue 3 of paper P0348R0): Example 2: template <typename U> void fun(U u = U()); struct X { X(int) {} }; template <class T> decltype(fun<T>()) g(int) { } template <class> void g(long) { } int main() { g<X>(0); } When is the substitution into the return type done? The current specification makes this example ill-formed because the failure to instantiate the default argument in the decltype operand is not in the immediate context of the substitution, although a plausible argument for making this a SFINAE case can be made. Meeting: (notes 2020-05-07) The first example under issue 3 of paper P0348R0 should become well-formed. SF F N A SA 0 1 4 3 6 The second example under issue 3 of paper P0348R0 should become well-formed. SF F N A SA 1 5 7 3 0 This is an issue. We’d like to see a paper addressing it. It should explore what “Immediate context” means. No objection to unanimous consent. Daveed / Hubert might entertain writing a paper explaining this. Ville emailed EWG about this. JF contacted Andrzej to see if he’s interested in addressing this. Not sure he is. Meeting 2020-10-28: Tomasz will write a paper which exposes the issue and what he thinks should be done (but not resolving wording itself). Hubert remembers an email about this, will find it and sync with JF. Meeting 2021-01-14: Andrzej wrote a paper for this (emailed 2021-01-12 to EWG). |
Paper needed | |
|
Core |
__func__ should be constexpr |
The definition of __func__ in 9.5.1 [dcl.fct.def.general] paragraph 8 is: static const char __func__[] = "function-name"; This prohibits its use in constant expressions, e.g., int main () { // error: the value of __func__ is not usable in a constant expression constexpr char c = __func__[0]; } Rationale (November, 2018): See also issue 1962, which asks that the type of __func__ be const char*. These two goals are incompatible. Meeting: handle with 1962. |
Paper needed |
8. Near-future EWG plans
We will continue to work on issue resolution and C++23, prioritizing according to [P0592R4].


Animations - Use one, or define your own.
Animations - Use one, or define your own.
jquery-confirm
v
-
docs
view on Github
Impression lies in what we see.
Different animations can be set for open and close events.
2D animations:
3D animations:
You can also create/define your own animations
$.confirm({
animation: 'zoom',
closeAnimation: 'scale'
});
// Available animations:
// right, left, bottom, top, rotate, none, opacity, scale, zoom,
// scaleY, scaleX, rotateY, rotateYR (reverse), rotateX, rotateXR (reverse)
Some eye candy thats in fashion.
$.confirm({
animationBounce: 1.5, // default is 1.2 whereas 1 is no bounce.
});
Adjust the duration of animation.
$.confirm({
animationSpeed: 2000 // 2 seconds
});
$.confirm({
animationSpeed: 200 // 0.2 seconds
});
Defining your custom animations lets you match your existing user interface.
Example for a newsflash animation.
These animations are define the starting point of the
openAnimation and ending point of the closeAnimation
.jconfirm .jconfirm-box.jconfirm-animation-news{
// the animation name is bob
transform: rotate(400deg) scale(0);
}
$.confirm({
animation: 'news',
closeAnimation: 'news',
});
The animation name should be lowercase, or they wont work.
.jconfirm-animation-animation-name
translates to 'animation-name'
.jconfirm-animation-animationhere
translates to 'animationhere'
This animation takes place when backgroundDismiss is false, or returns a falsy value.
Example for a newsflash animation.
These animations are define the starting point of the
openAnimation and ending point of the closeAnimation
.jconfirm .jconfirm-box.hilight.jconfirm-hilight-random {
/*the animation name is bob*/
transform: translate3d(0,0,0);
animation: random 2s;
}
@keyframes random{
10%, 90% {
transform: rotate(-2deg);
}
20%, 80% {
transform: rotate(4deg);
}
30%, 50%, 70% {
transform: rotate(-8deg);
}
40%, 60% {
transform: rotate(8deg);
}
}
$.confirm({
backgroundDismissAnimation: 'random',
});
The animation name should be lowercase, or they wont work.


{% include 'snippets/book.html' with book=activity.book size=large %}
{{ activity.name }}
{{ activity.rating | stars }}
{{ activity.review_content }}
{% elif activity.activity_type == 'Follow' %}
started following someone
{% else %}
{# generic handling for a misc activity, which perhaps should not be displayed at all #}
did {{ activity.activity_type }}
{% endif %}


An Electron-based light wallet (no need for chain copy nor VM) for Windows, OSX, and Linux users.
A high-performance block explorer and API laying the foundation for other projects.
COZ members coordinate efforts from multilingual translators to share information with the world.
A portal to unify developers on a single app. It will support projects, invites, and more!
We're working on lots of things; you can follow along and help vote on priorities on our Trello!
1 - There will be a council always composed of 9 members. They are the Council team in our organization.
2 - There will be a high council composed of 4 members of the council. They are the Maintainers of the Council team.
3 - Any member of CoZ can create and collaborate on projects.
4 - There will be a weekly report delivered to NEO by the high council via a PGP signed email and correspondent pull request on GitHub.
5 - In case of any support from NEO as reward or bounty, the funds will initially be held by a trusted third party in wallet AXSoNQEKjmqPBNPg5cNrHyWivfjok3Vj9D for distribution.
6 - After 1 September 2017, all CoZ funds will be held in a multi-sig wallet requiring a majority of the high council to unlock funding.
7 - Rewards distribution will be voted on by project before being sent. There must be a majority agreement of all 9 council members.
8 - All decisions not explicitly differentiated in this list will be voted upon as in item 7.
9 - Item 7 voting polls of the council will run for 1 week on the #council Slack channel and after closing will be published in the #develop channel.
10 - The high council will be voted upon each quarter, synchronizing with the quarters of the year. The first election will be on 1 October 2017. The newly elected high council can propose changes to these rules during the first week after the election. Changes will be voted upon as in item 7.
11 - Any member of the council or high council is free to forfeit their position at any time. When this happens, an election will take place and a majority of council members must decide upon a replacement.
12 - Any member of the council that does not vote on polls for more than 2 months will automatically forfeit their position.
© 2017 City Of Zion. Modified (a lot) from ProBootstrap


|
|||||||||||
| PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES |
| Class Summary | |
| AdminServlet | Proof-of-concept "management" servlet for Axis. |
| AxisHttpSession | An HTTP/Servlet implementation of Axis sessions. |
| AxisServlet | |
| AxisServletBase | Base class for servlets used in axis, has common methods to get and save the engine to a common location, currently the webapp's context, though some alternate persistence mechanism is always possible. |
| ChunkedInputStream | |
| ChunkedOutputStream | |
| CommonsHTTPSender | This class uses Jakarta Commons's HttpClient to call a SOAP server. |
| HTTPConstants | HTTP protocol and message context constants. |
| HTTPSender | This is meant to be used on a SOAP Client to call a SOAP server. |
| HTTPTransport | Extends Transport by implementing the setupMessageContext function to set HTTP-specific message context fields and transport chains. |
| NonBlockingBufferedInputStream | |
| ServletEndpointContextImpl | |
| SimpleAxisServer | This is a simple implementation of an HTTP server for processing SOAP requests via Apache's xml-axis. |
| SimpleAxisWorker | |
| SocketInputStream | The ONLY reason for this is so we can clean up sockets quicker/cleaner. |
|
|||||||||||
| PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES |


This is the site for Jovi, an MC based out of Massachusetts but working on a national, global, even universal level.
The objective is to build the culture and promote good music.
If you work for a blog, run a venue, make music, or just wanna say what up, you can contact him at:
Jovaninoelvillegas@gmail.com


PELLE THE CONQUEROR A film review by Ben Hoffman Copyright 1997 Ben Hoffman
A riveting film, a work of art. From the first frames where out of an opaque fog there appear the dim outlines of the masts of a schooner, the film is a masterpiece of photography and story telling.
The time is about the early 1900s. Huddled on the ship are immigrants from Sweden who are going to Denmark for work because of bad times in Sweden. Among the passengers is an older man (Max Von Sydow), a widower since a year, and his 10-year-old son, Pelle (Pelle Hvenegaard).
The father tells Pelle that in this new land children do not have to work. They can spend their time at play. But we soon see that it is all bravado.  Whether because of circumstances or of an innate lack of character it becomes apparent that Father meets each challenge by backing down. On the other hand one must feel sorry for this pathetic man because he cannot afford to take risks.
On the dock people are being hired. Not surprisingly, he is the last one to be chosen, along with his son. It appears to be some kind of indentured servitude; lodging and food, and after several years there is the payoff in money and becoming a free man. Lodging for Pelle and his father consists of a partitioned portion of the barn, next to the cattle and the chickens, hardly the life he had described to his son.
Running through the film are several other stories that blend with the main one, each interesting in its own right. There is the fascinating tale of the beautiful young working woman who is in love with a merchant's son; there is the dream of one worker of being free the next year and of going to America to make his fortune about which, poor man, he has no doubts.
Throughout, the photography is beautiful, with scenes that are sheer Breughel or Millet. Other scenes, with snow blowing icily across the fields, convey the bitter cold. And there is the raging sea, the fog, the broken floating ice floes all interwoven to emphasize the hardships all must face in that climate. You will marvel at the nastiness of adults and children, alike, when they have the power to impose their will on those not in a position to fight back. A powerful masterpiece of man's inhumanity to man.
In Danish and Swedish with English subtitles.
Directed by Bille August.
4 Bytes
4 bytes = Superb 3 bytes = Too good to miss 2 bytes = Average 1 byte = Save your money
Ben Hoffman
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


Do you notice that there is a big gap between retail price and wholesale price? Consumers coming into the shops alone do not get a good deal. Why not form a consumer-Co-Op? Why not buy one, instead of two, directly to get better price?
Sounds similar? Like Vendor Relationship Management ? Crowd ownership (we just created at #SWHK to differentiate from crowd funding)?
#coopist_hkfood


{% extends 'ideax/base.html' %} {% load staticfiles i18n %} {% block content %}
{% trans 'With IdeiaX you have an open channel for innovation, getting ideas from all parties, evaluating and making them happen!' %}
{% trans 'IdeiaX is the channel to spread and share your ideas, allowing your peers to contribute, discuss and collaborate to grow it.' %}
{% trans 'In the same way, you can see other posted ideas, interacting with your opinion, asking and opining to further improve other ideas.' %}
{% trans 'Everyone within the company or project can collaborate. Innovation can come from everyone.' %}
{% trans 'Ideas can be organized, matured and evaluated, allowing a flow for the innovation management.' %}
{% trans 'Through APIs is possible to integrate with other tools. Integrating with a project management tool is possible to create a project based on an idea registered in IdeaX.' %}


--- layout: bloglayout title: UI Guy - Devang Paliwal tagline: ---
Leading the frontend efforts at Mygola Inc. i take pride in creating good looking interactive web interfaces. I love the WEB. I have experience in designing and implementing loosely coupled,component based front end architectures. I have worked with Cisco Systems, Pramati Technologies, Verse Innovations on variety of front-end projects.
HTML
CSS
JAVASCRIPT
BACKBONE
JAVASCRIPTMVC
JQUERY
MODERNIZR
DESIGN PATTERNS
BITS PILANI
~ Masters in Software Systems / 2009-2011
Dhirubhai Ambani Institute of Information and Communication Technology
~ Btech / 2002-2006


Class BaseLeaderboardInterface
Base abstract class for controlling the interface related to displaying the latest standings for a leaderboard.
Inherited Members
Namespace: PlayGen.SUGAR.Unity
Assembly: PlayGen.SUGAR.Unity.dll
Syntax
public abstract class BaseLeaderboardInterface : BaseInterface
Fields
_alliancesButton
Button used to change the current leaderboard filter to 'Alliances'. Can be left null.
Declaration
protected Button _alliancesButton
Field Value
| Type | Description |
|---|---|
| Button |
_friendsButton
Button used to change the current leaderboard filter to 'Friends'. Can be left null.
Declaration
protected Button _friendsButton
Field Value
| Type | Description |
|---|---|
| Button |
_leaderboardName
Text used for displaying leaderboard name. Can be left null.
Declaration
protected Text _leaderboardName
Field Value
| Type | Description |
|---|---|
| Text |
_leaderboardType
Text used for displaying current leaderboard filter. Can be left null.
Declaration
protected Text _leaderboardType
Field Value
| Type | Description |
|---|---|
| Text |
_membersButton
Button used to change the current leaderboard filter to 'Group Members'. Can be left null.
Declaration
protected Button _membersButton
Field Value
| Type | Description |
|---|---|
| Button |
_nearButton
Button used to change the current leaderboard filter to 'Near'. Can be left null.
Declaration
protected Button _nearButton
Field Value
| Type | Description |
|---|---|
| Button |
_topButton
Button used to change the current leaderboard filter to 'Top'. Can be left null.
Declaration
protected Button _topButton
Field Value
| Type | Description |
|---|---|
| Button |
Methods
Awake()
Base Awake method adds onClick listeners for the close, signin, top, near, friends, group member and alliance filter buttons.
Declaration
protected override void Awake()
Overrides
ErrorDraw(Boolean)
Used to set error text in case of no user being signed in, loading issues or if no results are available. Filter button interactable set to false if no user is signed in or loading issues occur.
Declaration
protected override void ErrorDraw(bool loadingSuccess)
Parameters
| Type | Name | Description |
|---|---|---|
| System.Boolean | loadingSuccess | Was the data successfully loaded? |
Overrides
HideInterfaces()
Hides Account, Evaluation, UserFriend, GroupMember and UserGroup UI objects. Makes filter buttons interactable. Set leaderboard related text.
Declaration
protected override void HideInterfaces()
Overrides
IsValid(ActorResponse, ActorType)
If the response actor isn't null, does the leaerboard ActorType match the actorType provided or the Combined ActorType
Declaration
protected bool IsValid(ActorResponse response, ActorType actorType)
Parameters
| Type | Name | Description |
|---|---|---|
| ActorResponse | response | Actor that would be used for the filter |
| ActorType | actorType | Valid actorType for the leaderboard if response is used as the basis |
Returns
| Type | Description |
|---|---|
| System.Boolean |
LoadErrorText()
Get error string from Localization with key "LEADERBOARD_LOAD_ERROR" if there were issues loading the leaderboard standings list.
Declaration
protected override string LoadErrorText()
Returns
| Type | Description |
|---|---|
| System.String |
Overrides
NoResultsErrorText()
Get error string from Localization with key "NO_LEADERBOARD_ERROR" if there were no leaderboard standings to display.
Declaration
protected override string NoResultsErrorText()
Returns
| Type | Description |
|---|---|
| System.String |
Overrides
SetInteractable(Button, Boolean)
Set the button's interactable value
Declaration
protected void SetInteractable(Button button, bool interactable = true)
Parameters
| Type | Name | Description |
|---|---|---|
| Button | button | Button to enable/disable the use of |
| System.Boolean | interactable | Value to change the button's interactable boolean to |
UpdateFilter(LeaderboardFilterType)
Change the leaderboard filter currently being used
Declaration
protected void UpdateFilter(LeaderboardFilterType filter)
Parameters
| Type | Name | Description |
|---|---|---|
| LeaderboardFilterType | filter | The filter to use for display leaderboard standings |
UpdateMultiplePerActor(Boolean)
Change the multiple per actor setting currently being used
Declaration
protected void UpdateMultiplePerActor(bool multiplePerActor)
Parameters
| Type | Name | Description |
|---|---|---|
| System.Boolean | multiplePerActor | Setting that determines if actors can appear on a leaderboard multiple times |