Set 40 years in the future, guests enter the home of Amelia Bloom, a star employee at DesignCraft - the world leader in at-home technology. Amelia has developed deep suspicions of what her company is up to and what exactly they intend to do with all this data they've collected. In the midst of a desparate attempt to rupture the power of a tech giant, audience members are brought into the center of the drama to have the chance to experience the future first hand. Everyone who enters will be able to freely explore, play, and hopefully question what's at stake with all this data we're collecting.
We are an immersive theatre and interactive art project currently working in University of Colorado in the Department of Computer Science in collaboration with the CU Boulder Department of Theatre and Dance and the ATLAS Institute. Our project received support from the John S. and James L. Knight Foundation’s Knight News Challenge and CU-Boulder's Engineering Excellence Fund. Our first production is presented by ATLAS CMAP, an incubator for the novel and experimental use of technology in music, dance, visual art, theater, film, and hybrid and diverse new media.
Our project's goal is to engage a broad audience of people who are interested in the future and ethics of data sharing online. More than discussing privacy, we aim to show people the possibilities around product development, research, artificial intelligence, and human inference given the amounts of data owned by third-parties. To achieve this, we ask people to share their data with us for the duration of the show so that we can meet guests at the level of their actual lives, only to then take them somewhere else to expand their imagination.
Our first show will happen April 28 - May 1, 2016 in Boulder, CO at ATLAS's Black Box Theater. We intend to move the show into other locations and run public events that open public dialogue around the ethical considerations we have placed in the performance. If you are interested in seeing this production come to your location or to collaborate on a run of it, please contact our project lead at: michael[dot]skirpan[at]colorado[dot]edu
Michael Skirpan - Writer, Producer, Interaction Design, Creative Lead
mwskirpan.com | michael[dot]skirpan[at]colorado[dot]edu | github | @mwskirpan
Jacqueline Cameron - Project Coordinator, Producer, Design
jacqueline[dot]cameron[at]colorado[dot]edu
William Lewis - Director, Producer
level16.org | william[dot]lewis-2[at]colorado[dot]edu
Micha Gorelick - Chief Data Engineer
micha.codes | micha[at]fastforwardlabs[dot]com | github | @mynameisfiber
Danny Rankin - Scenic Design
daniel[dot]rankin[at]me[dot]com
Nathan Liddell - Build Engineer
nmliddell[at]gmail[dot]com
Alex Klinger - Graphics, Lighting, and Sound Design
Tumblr | alxklngr[at]gmail[dot]com
Felix Vietmeyer - Electrical Design
felix[dot]vietmeyer[at]gmail[dot]com | github
Ericka Skirpan - Costume Design
eskirpan[at]gmail[dot]com
Paige Canepa Olson - Wardrobe Head
Peyman Mortazavi - CS Research Assistant
pey[dot]mortazavi[at]gmail[dot]com | github
Slaton Spangler - CS Research Assistant
slaton.info | slaton[dot]spangler[at]colorado[dot]edu
Leif Waldner - CS Research Assistant
leif[dot]waldner[at]colorado[dot]edu
Michael Aaron - Coding Assistant
michael[dot]drew[dot]aaron[at]gmail[dot]com
Sam Korn - Coding Assistant
korn94sam[at]gmail[dot]com | website
Mandy Greenlee - Amelia Bloom
Shayn Herndon - Don DeClaire
Niki Tulk - Felicia Emerick
Samantha Yoho - Lily Jordan
Nathan Chistensen - Evan Espie
Alex Campbell - Bo Rakenfold
Taralynn Dorr - Agent
Sasha Georges - Reporter
Gina Braswell - Assistant Director
Paige Canepa Olson - Assistant Director
Hayden Nault - Production Stage Manager
Sarah Baughman - Stage Manager
McKenna Warren - Stage Manager
Sarah Johnson - Dramaturg
Patrick Cooper - Design and Build Assistant
coopaloopster[at]gmail[dot]com
Cindy Vo - Marketing and Design Assistant
Sabina Hayutin - Build Assistant
Susie Gomez - Fabrication Assistant
susana[dot]gomezburgos[at]colorado[dot]edu
Hilary Mason - Founder - Fast Forward Labs
hilarymason.com | @hmason
Tom Yeh - Professor, Computer Science at CU-Boulder
tom[dot]yeh[at]colorado[dot]edu | tomyeh.info
Once you authenticate with an account, an automated service goes through data that is relevant to a particular exhibit within our production. All of your data is encrypted and left, unable to be seen, until the night of the show when we put a private key on a bracelet upon checking in. We will have a human look at small pieces of data the night of the show needed to do personalization of certain small parts; however, this data will come from your public accounts.
Your GMail data will never be looked at by another human and will remain encrypted, stored, and only shown in the event you consent to using an exhibit with your bracelet.
Because our interest is purely in educating and entertaining you. We derive no personal gain or monetary value from your data. We never sell or share any of your data (unlike your providers who own your data). Our privacy policy is actually MORE STRICT and MORE SECURE than other online providers. All of the data you share with us gets immediately encrypted such that even our team cannot see your data. The only way for your data to be unencrypted is for multiple of the production staff to come together in the same room and provide multiple private keys (which we do each night of the show). Then, following the night of your visit, we permanently delete everything you shared.
No. Interacting with your data is entirely up to you during the show. We will not use your data to make fun of or harm you. However, we do have some surprises in the show that may involve you. This is immersive theatre so you should anticipate the possibility of having yourself addressed in the show. Also, since the interactions are both private and public forms, if you choose to interact with an exhibit, we cannot guarantee you won't feel nervous or uncomfortable. But our exhibits are not designed to harm or slander you. Do remember this is meant to be an impactful experience so while we do take serious measures to not violate your privacy or put you in negative situations. The point of coming is to take the small risk of experiencing your online data in an artistic, thought-provoking format.
We want to open up more conversation and improve people's understanding of how personal data is being used to develop new products, advertise, perform research, and do surveillance. It's our view that most users do not know what their data is used for nor what it is capable of. We also see technologists interested in thinking through their decisions and having more insight into how users feel about what they are doing. So we want to close the gap between technologists and users to improve dialogue around ethics and possible futures to help move toward a more moral and transparent society.
We also simply want to show you something beautiful and enjoyable. Our hope is to run this show in many cities and reach many people so that more individuals can make better choices online and have an informed voice in discussions about our shared future.
Oh yeah. That's why we're doing this -- because the world is super weird so we should probably talk about it.


Daily Digest #81 ‐ August 11, 2018 How JavaScript works: WebRTC and the mechanics of peer to peer networking Debugging Serverless Apps Multi-server Chat in Node Without a Database XDP in Practice: DDoS Mitigation @Cloudflare Unikraft - Unleashing the Power of Unikernels
Daily Digest #80 ‐ August 10, 2018 Guppy – 🐠A friendly application manager and task runner for React.js The Forwardable module in Ruby — Part I Git Shortcut 📟 Building Web based UIs for Terminals using JavaScript – because, why not? Transforming Financial Forecasting with Data Science and Machine Learning at Uber
Daily Digest #79 ‐ August 9, 2018 Experiences from Building an Event-Sourced System with Kafka Streams vue-pattern – Useful Vue patterns Best Practices for ML Engineering How to beat Linkedin: The Game The worst truism in information security
Daily Digest #78 ‐ August 8, 2018 How I gained commit access to Homebrew in 30 minutes Scaling Microservices with Message Queues, Spring Boot and Kubernetes Discussing Serverless with Stackery and Google Your Infrastructure as Code 🌩 CloudFormation Vs Terraform? A sysadmin’s guide to Ansible: How to simplify tasks
Daily Digest #77 ‐ August 7, 2018 Firefox Pioneer New – Lifecycle Management for Amazon EBS Snapshots CAP Theorem illustrated Add Constrained Optimization To Your Toolbelt Headless CMS vs Traditional CMS: A Deep Dive


Public Types | |
| typedef select_type_traits < typename support::coordinate < P1 >::type, typename support::coordinate< P2 > ::type >::type | T |
Public Member Functions | |
| distance_result | operator() (const P1 &p1, const P2 &p2) const |
Static Public Member Functions | |
| static bool | squared () |
| typedef select_type_traits< typename support::coordinate<P1>::type, typename support::coordinate<P2>::type >::type geometry::strategy::distance::pythagoras< P1, P2 >::T |
| distance_result geometry::strategy::distance::pythagoras< P1, P2 >::operator() | ( | const P1 & | p1, | |
| const P2 & | p2 | |||
| ) | const |
| static bool geometry::strategy::distance::pythagoras< P1, P2 >::squared | ( | ) | [static] |
|
October 14, 2008 |
Copyright © 1995-2008 Barend Gehrels, Geodan Holding B.V. Amsterdam, the Netherlands Copyright © 2008 Bruno Lalande, Paris, France |


A short tutorial on how to do data testing.
I suggest having the notebooks open through GitHub inside your browser. The Jupyter notebooks are mostly a presentation tool; iterative prototyping can be done using the IPython shell or Python interpreter. Almost all of what we will do involves the Terminal and your favourite plain text editor.
I am assuming you are of the following type of coder:
.apply()
function).with ....
),assert conditions1 == condition2
),with open(....) as f:...
),[a for a in container if condition(a)]
),isinstance(obj, type) or hasattr(obj, attr)
).numpy
, particularly the the array.min()
, array.max()
, array.mean()
, array.std()
, and numpy.allclose(a1, a2)
function calls.conda
setupI recommend using the Anaconda distribution of Python. This is best supported for Mac OS X and Linux-based systems.
To get setup, create a conda
environment based on the provided environment.yml
spec file. Run the following commands in your bash terminal.
$ bash conda-setup.sh
pip
setupThe alternative way is to use a virtualenv environment:
$ bash venv-setup.sh
$ source datatest/bin/activate
To check whether the environment is correctly setup, run the checkenv.py
script:
$ python checkenv.py
It should print to your terminal in green text, All packages found; environment checks passed.
. Otherwise, conda
or pip
install the necessary packages stated (they will show up one by one).


|
| static const uint8_t | kIpVersion = 4 |
| |
| static const uint8_t | kPktPriority = 7 << 5 |
| |
|
static const uint8_t | kPktDelay = 7 << 4 |
| |
|
static const uint8_t | kPktThroughput = 7 << 3 |
| |
|
static const uint8_t | kPktReliability = 7 << 2 |
| |
| static const uint16_t | kFlagNoFragment = 1 << 14 |
| |
|
static const uint16_t | kFlagMoreFragment = 1 << 13 |
| |
| static const uint8_t | kProtocolTcp = 0x06 |
| |
|
static const uint8_t | kProtocolUdp = 0x11 |
| |
| uint16_t Ipv4Layer::CheckSum |
( |
Header * |
header, |
|
|
uint32_t |
size |
|
) |
| |
|
inline |
Calculate IPv4 checksum.
- Parameters
-
| header | IPv4 header. |
| size | IPv4 header length. |
- Returns
- checksum.
Filter the received packet by its header content.
- Parameters
-
- Returns
- if the packet is to be received or not.
Reimplemented from ProtocolStackLayer.
| bool Ipv4Layer::GetHardwareDestinationAddress |
( |
NetDev::Packet * |
packet, |
|
|
uint8_t * |
addr |
|
) |
| |
|
static |
Get hardware destination address from IPv4 address embedded in the packet.
- Parameters
-
| packet | IPv4 packet. |
| addr | found hardware address. |
- Returns
- if hardware address found in ARP table.
| virtual int Ipv4Layer::GetProtocolHeaderLength |
( |
| ) |
|
|
inlineprotectedvirtual |
Return IPv4 header size.
- Returns
- protocol header length.
Reimplemented from ProtocolStackLayer.
Make contents of the header before transmitting the packet.
- Parameters
-
- Returns
- if succeeds.
Reimplemented from ProtocolStackLayer.
| void Ipv4Layer::SetAddress |
( |
uint32_t |
ipv4_addr | ) |
|
|
inline |
Set my IPv4 address.
- Parameters
-
| void Ipv4Layer::SetPeerAddress |
( |
uint32_t |
ipv4_addr | ) |
|
|
inline |
Set peer IPv4 address.
- Parameters
-
| void Ipv4Layer::SetProtocol |
( |
uint8_t |
protocol | ) |
|
|
inline |
Set upper layer protocol type.
- Parameters
-
| uint16_t Ipv4Layer::_id = 0 |
|
private |
IPv4 address assigned to the network device under this layer
| uint8_t Ipv4Layer::_ttl = 64 |
|
private |
time to live (number of hops)
| uint8_t Ipv4Layer::_upper_protocol |
|
private |
layer 4 protocol type stacked on this layer
| const uint32_t Ipv4Layer::kAddressNotSet = 0 |
|
staticprivate |
constant representing no IPv4 address is set
| const uint16_t Ipv4Layer::kFlagNoFragment = 1 << 14 |
|
static |
| const uint8_t Ipv4Layer::kIpVersion = 4 |
|
static |
| const uint8_t Ipv4Layer::kPktPriority = 7 << 5 |
|
static |
| const uint8_t Ipv4Layer::kProtocolTcp = 0x06 |
|
static |
The documentation for this class was generated from the following files:
- source/kernel/net/ip.h
- source/kernel/net/ip.cc


To get started select "create bot." You will create a Developer Application Developer Application to connect the bot to Glimesh. The account that creates the application will be the account that the bot uses.
Use the following values
| Property | Value |
|---|---|
| Name | Glimboi CHANNEL_NAME |
| Homepage | http://localhost:3000 |
| Description | Glimboi chatbot for CHANNEL_NAME |
| Image | Optional |
| Allowed Redirect URIs | http://localhost:3000/success |
Save the application. Then enter the client ID and secret key on the right. Save them to GlimBoi. Then request a token. After the initial request Glimboi will automatically authenticate itself on launch. If any problems arise you can simply request another token.


Emmerdale fans horrified as Arthur punches Archie unconscious and blames Jimmy
Arthur has been lashing out of late
by Helen FearArthur Thomas lashed out in anger at Archie Sharma last night, and Emmerdale fans were left horrified by his behaviour.
On Tuesday night (November 12), Arthur blamed Archie for 'ruining' his dad's birthday and turned nasty towards the young boy - punching him and knocking him to the floor.
Read more: Emmerdale SPOILERS: Sarah risks her life by taking drugs
In a disturbing sequence of events, Archie was knocked unconscious and left lifeless on the floor of the kitchen.
The nasty altercation came after Arthur told him no one missed his mum Rachel now that she was dead.
He made it clear he hadn't been welcome to the picnic for Ashley's birthday, before lashing out with his fists.
Read more: Emmerdale SPOILERS: Lydia finds out she could have Huntington's disease
When Laurel and Jai found poor Archie on the floor, Arthur told them he'd fell by accident.
But later, Jai and Laurel found more bruises on him.
However, when they questioned Archie about how he got the marks, Arthur blurted out that Jimmy King was to blame!
While some viewers branded Arthur a "demon child", others insisted blaming the boy was too easy, and suggested he needs help with his anger issues.
Ever since Archie appeared in the Dales, Arthur has clearly been jealous of the attention he has been getting from Laurel.
But blaming Jimmy was a step too far for some of those watching from home, who claim he could never hurt a fly.
One of the Arthur haters tweeted: "Whoa Arthur!
Another said: "Poor little Archie... Arthur's a bully."

"Ashley will be turning in his grave at Arthur, what has happened to him? Vile child," blasted another.
However, some fans were more sympathetic, with one tweeting: "Arthur isn't vile. What Arthur is doing to Archie is awful and blaming Jimmy for it terrible. If you listen to what Arthur says to Archie, to me it explains a lot.
"Arthur needs someone to recognise that he needs attention and understanding. I'm not excusing bullying, far from it."
Another said: "I wish someone would recognise what Arthur is going through #Emmerdale."
A third added: "Oh this Arthur and Archie stuff is sad.
"Laurel is so insensitive," said one more.  Why did she ruin something so special for Arthur?"
Many others were livid that this is the start of an upsetting child abuse storyline for Jimmy, with one typing: "Jimmy getting this child abuse storyline. Why do bad things happen to good people? Gonna be hard to watch, hopefully people will believe him #Emmerdale."
Another said: "Poor Jimmy getting the blame."
A third added: "What the hell? Arthur blamed someone like Jimmy, who couldn't even hurt a fly."
"If they honestly believe Jimmy would hurt a child, they need their heads' read," lamented another.
Appearing on Lorraine on Tuesday, actor Nick Miles confirmed his character Jimmy is in for an "awful" time as the character's child abuse storyline unfolds.
Talking of the dark plotline, he added: "It will rumble through up until Christmas. It is tough."
How do you feel about this storyline? Let us know on our Facebook page @EntertaimentDailyFix .


Sign in
Use your registered username
{% csrf_token %}
{{message}}
Forgot Username?
Forgot Password?
Sign in
Not a User?
Create Account


Features
- Support app links, ex: whatsapp://send?text={your text} , alipays://
- Custom links
- Click statistics
- Limitless content
Request Method
GET/POST
Address
https://aid.im/api
request data type
form
ex:
code=200&id=ABC2&url=http://google.com
| PARAMETER |
TYPE |
REQUIRED |
MEMO |
| url |
string |
Y |
max length < 2083 |
| code |
string |
Y |
http status code, accept 301, 302, 303, 307 and 200 |
| id |
string |
N |
(optional) custom id, 4~12 characters, accept A-Z,a-z,0-9 and '_' |
* 200 code will use js "window.location.href" to redirect, http,https,ftp,tcp,udp,wss support all code. App links or universal links only accept 200 to open, ex: myapp://
Support App links
whatsapp://send?text={your text}
WARNING: your shortened link will be delete if 30 days without any visit
Support US
AID.im is a nonprofit site that provides free service and opensource code in
github.com/astinx/aid.im, you can buy a cup of coffee to support this site and this project


We're excited about your choice to join our site.
A brief tutorial on using the site.
Create Coupon:All fields must be entered.
Note!Expired date must be after start date, and both after today's date.
The coupon price should be more than 0.5.
The amount of coupons at least one.
Message - Up to 180 characters.
My coupons:View all of my coupons in the form of a customer view.
There is an option to upgrade and delete each coupon.
My coupons filtered By type:Show all my coupons by type depending on the type entered in the field
Here too you can upgrade or delete a coupon.
My coupons filtered By id:Show a coupon depending on the id entered in the field
Here too you can upgrade or delete a coupon.
My coupons filtered By End date:Show all my coupons up to the date entered in the field
Here too you can upgrade or delete a coupon.
Company details:View the company's personal details
To exit the system safely, click the Logout button


Dominant West Indies eye series win
Afg v WI, 2nd T20I, preview
After being swept clean in the ODIs, Afghanistan were outclassed in the first T20I as well. Can West Indies maintain their dominance and seal the series in the second match on Saturday, 16 November?
Overview
Afghanistan v West Indies, 2nd T20I
Ekana International Cricket Stadium, Lucknow
Saturday, 16 November; 07:00pm local, 12:30am GMT
Afghanistan desperately need to find some inspiration, especially in the batting department, if they are to keep West Indies from winning the T20I series with a game to spare.
Afghanistan struggled to put on partnerships throughout the ODI series, and that remained the theme during the first game in the shortest format too. They will want the more established players, such as Asghar Afghan, Najibullah Zadran and Mohammad Nabi to lead the way in that front.
West Indies will be keen to close out the series without giving Afghanistan a sniff. Their batsmen have done a great job against the high-quality Afghanistan spinners this entire tour. But as much as they will be keen to win the series, it is also a test for newcomers to the side, such as Brandon King and Hayden Walsh. How they perform in the next game and the one after that will be of particular importance, given that the management will be thinking of candidates for next year's ICC Men's T20 World Cup.
Remember the last time
Evin Lewis looked in red-hot form as he smacked four fours and six sixes in his 41-ball 68. The Afghanistan bowlers did well enough to keep making breakthroughs at the other end, but captain Kieron Pollard finished the innings off with a responsible 22-ball 32*, featuring two fours and a six, to take West Indies to 164/5. The West Indies fast bowlers then reduced Afghanistan to 7/2 inside three overs. Kesrick Williams, with his crafty variations, saw to it that Afghanistan were not able to claw their way back in. He finished with 3/17 from his four overs to restrict Afghanistan to 134/9.
What they said
Rashid Khan, Afghanistan captain: "We have plans about what kind of team we want to build in the next five years, so we are giving chances to youngsters. Hopefully, we develop a strong team in time for the Asia Cup and the World Cup."
Kieron Pollard, West Indies captain: "The partnership between Lewis and Hetmyer set the match up. This isn't one of the easiest wickets to bat on.  It's when you have to play smart cricket and manoeuvre the fielder."
Conditions
Weather is expected to be clear and pleasant. The pitch has played a few tricks at the Ekana International Cricket Stadium, but there are runs to be had once the batsmen get their eyes in.


KUWK: Kendall Jenner Hints She Might Want To ‘Start A Family’ While Playing With Kimye’s Sons – Check Out The Cute Pics!
by Ashley MitchellThe supermodel is the only one that is yet to become a parent out of the whole Kardashian-Jenner clan. That being said, is Kendall Jenner ready to take on that role as well?
Whether she is getting any closer to wanting kids of her own or not, it’s safe to say that Kendall is an amazing aunt to her 10 nephews and nieces!
But since she knows that some fans would love to see her start a family early on like her younger sister, Kylie, she played around with the idea in a new post!
Kendall took to her platform to share a couple of cute pics that showed her doing her duty as the cool aunt and playing with Kim Kardashian and Kanye West’s sons, Saint and Psalm.
The photos are definitely super adorable but the caption managed to gather almost the same amount of attention!
After all, she suggested she may have baby fever, writing: ‘everyone in favor of Fai and i starting a family say ‘I’ ✋🏼.’
A couple of snaps showed the model goofing around with the older child, even holding Saint upside down on her knees while also holding little Psalm in her arms. Aww….
As for the one she mentioned in the cation, it was her BFF Fai Khadra, who was also hanging out with her and the kids.
The two close friends were linked romantically before and even went to Justin Bieber and Hailey Baldwin’s wedding together as each other’s dates.
However, Kendall made it very clear that ‘We don’t date, he’s just my date,’ when she posted a pic from the singer and model pair’s ceremony.
But, as it seems, fans are not the only ones shipping the two since her famous friends were quick to show enthusiasm over the idea of Kendall and Fai starting a family together.
Hailey Baldwin, in particular, was super excited, writing sever comments about it in a row, reading: ‘I SAY YES.’ / ‘MEEEEE.’ / ‘I DOOO.’ / ‘IIIII.’


US House approves bill to avert government shutdown this week
WASHINGTON, Nov 20 — The US House of Representatives yesterday approved legislation to avert a widespread government shutdown later this week with a bill extending temporary federal funding through December 20.
The legislation passed the House by a vote of 231-192, with all but a dozen Republicans voting against the funding.
It now goes to the Senate, which will aim to approve it before midnight tomorrow when existing funds expire. Senate Majority Leader Mitch McConnell on Monday said the White House had indicated its support for the bill.
This second stop-gap bill since September is needed because Congress has not completed a series of regular appropriations bills for the fiscal year that began on October 1.
That in part is because of disagreements between Republican President Donald Trump and Democrats, who control the House, over the billions of dollars he wants to build a US-Mexico border wall.
The same disagreements resulted in a record-long, 35-day partial government shutdown that began late last December and extended into early 2019. — Reuters


AngularJS & Firebase App!
Email
Enter a valid email.
Password
Min password length is 8 characters.
{{register.regErrorMessage}}
Sign In
Sign In


Jayanagar 4th Block, Dhaka, Bangladesh
Call now:<PHONE_NUMBER>7
Mr. Example Name
Photographer
5 Years
50k
<EMAIL_ADDRESS>0123456789
Full Address, Dhaka-1000, bangladesh


Our team
George E. Hardin
Founder
With an aim of providing top-class and well-maintained Retro Cars to the customers, Mr. Lorem Ipsum laid the foundation stone of this organisation in Lorem, who has been passionately following his dreams of restoring cars for over 3 decades. He has been professionally trained in Ipsum. He has worked for the top companies like Ipsum, Lorem, Ipsum and many more. He has also won several awards in this field.
Anita J. Williamson
CEO
With an aim of providing top-class and well-maintained Retro Cars to the customers, Mr. Lorem Ipsum laid the foundation stone of this organisation in Lorem, who has been passionately following his dreams of restoring cars for over 3 decades. He has been professionally trained in Ipsum. He has worked for the top companies like Ipsum, Lorem, Ipsum and many more. He has also won several awards in this field.
John T. Velez
Managing Director
With an aim of providing top-class and well-maintained Retro Cars to the customers, Mr. Lorem Ipsum laid the foundation stone of this organisation in Lorem, who has been passionately following his dreams of restoring cars for over 3 decades. He has been professionally trained in Ipsum. He has worked for the top companies like Ipsum, Lorem, Ipsum and many more. He has also won several awards in this field.


tDCS stimulation motor GABA changes Glx Transcranial sensorimotor cortex current left Brain intervention brain anodal HD-tDCS direct right Stimulation transcranial data learning group hand {border-style pediatric using px;} #ffffff;} Fig Sciences compared metabolite study a-tDCS studies task change children contralateral editing following performance response Calgary, Magnetic Research concentration cortical participants significant weeks Electrophysiology MEGA-PRESS PPT effects glutamate metabolites relationship size skill time Biology Current GABA-edited Health Life Stimulation: adult groups (effect Direct Harris Kirton Nitsche Participants University developing estimate excitability follow sham shown spectroscopy training used AB, Canada However, MRS Neurosci. Writing [], greater observed results typically Bikson Data Direct-Current acquisition analysis associated correction days experimental high improvement levels magnetic non-invasive px; review site suggest suggests tissue voxel {font-family (HD-tDCS) Boggio Datta Edden Effects Medicine Paulus Purdue Resonance Stimul. conventional definition effect font-size grey matter plasticity possible ppm resonance score seen showed spectra tDCS, .). Antal Ciechanski Fregni Magn Methodology Motor Neurophysiology Neuroscience PRESS Pegboard Reson Spectroscopy creatine did difference double; electrode electrodes including increases induced learning. literature measured multiple non-dominant phase pulse reported signal stimulation, stroke .), ./j.brs... Analysis Calgary Carlson Changes Metabolites Modulation Neurophysiol. Stagg acquired adults analyses assessments available baseline bold border-color border-width brain. different disorders healthy human improvements increased inhibition inhibitory model outcomes performed placed post potential primary quality ramped received single solid; standard stimulation. water white {font-style {font-weight < (PPT (tDCS) -day ./mrm. Children Cohen Cole Curr Day Department Diagnostic FWHM Funding Gasparovic Giuffre Glx, Hum Institute, Med. Metabolite Methods Neurochemistry Neurotransmitters: Physiology Project Radiology Reis Res. Rigonatti Similarly, Task administration anode area assessment balance comparisons concentrations consecutive courier; curation decrease decreased em; facilitates fit fixed glutamine group, hemisphere mean measure pain positive protocol pt;} range sequence shows specific specifically suggested tDCS. target targeted targeting therapeutic week


Thanks for checking out the WhenHub API! These samples are here to help you see how to work with the API in real setting and to inspire your creativity. The samples are split up into different categories in case you want to see specific functionalities. Click the Display tab if you mainly want to see retrieving information and click the Edit tab if you're more intrested in posting data.
Many of the samples require that you get an Access Token from your WhenHub profile. If you're not sure where to get it, these directions will clear things up for you. While you're there, make sure you check out the Reference page, it will be helpful tool as you continue using the API.
Embed a public Whencast on any page using Javascript. This is one of the few exmamples that does not require an Access Token.
This sample uses simple Jquery to read data and display it.
Features:
This is a sample using Angular 4. The sample includes the following features:
This is a sample using React JS. The sample includes the following features:


Login to the Internet Archive < Previous example | Next example >
Type in email and password to login


Methods of Class Directory
- Directory
- Directory(
-
| virtual |
abstract |
const |
volatile |
template |
static |
inline |
C-linkage |
| NO |
NO |
NO |
NO |
NO |
NO |
NO |
NO |
- Summary
- Copy constructor.
- operator=
- Directory & operator=(
-
| virtual |
abstract |
const |
volatile |
template |
static |
inline |
C-linkage |
| NO |
NO |
NO |
NO |
NO |
NO |
NO |
NO |
- Summary
- Assignment operator.
- Directory
- Directory(
-
| virtual |
abstract |
const |
volatile |
template |
static |
inline |
C-linkage |
| NO |
NO |
NO |
NO |
NO |
NO |
YES |
NO |
- Summary
- Constructor.
- Parameters
| strPath |
The full qualified URL of the directory.
Relative URLs are not allowed.
|
- ~Directory
- ~Directory();
-
| virtual |
abstract |
const |
volatile |
template |
static |
inline |
C-linkage |
| NO |
NO |
NO |
NO |
NO |
NO |
YES |
NO |
- Summary
- Destructor.
- open
- RC open();
-
| virtual |
abstract |
const |
volatile |
template |
static |
inline |
C-linkage |
| NO |
NO |
NO |
NO |
NO |
NO |
YES |
NO |
- Summary
- Open a directory for enumerating its contents.
- Return
-
E_None on success
E_INVAL the format of the parameters was not valid
E_NOENT the specified path doesn't exist
E_NOTDIR the specified path is not an directory
E_NOMEM not enough memory for allocating structures
E_ACCES permission denied
E_MFILE too many open files used by the process
E_NFILE too many open files in the system
E_NAMETOOLONG File name too long
E_LOOP Too many symbolic links encountered
- See Also
- getNextItem()
close()
- isOpen
- sal_Bool isOpen();
-
| virtual |
abstract |
const |
volatile |
template |
static |
inline |
C-linkage |
| NO |
NO |
NO |
NO |
NO |
NO |
YES |
NO |
- Summary
- Query if directory is open.
- Description
- Query if directory is open and so item enumeration is valid.
- Return
-
sal_True if the directory is open else sal_False.
- See Also
- open()
close()
- close
- RC close();
-
| virtual |
abstract |
const |
volatile |
template |
static |
inline |
C-linkage |
| NO |
NO |
NO |
NO |
NO |
NO |
YES |
NO |
- Summary
- Close a directory.
- Return
-
E_None on success
E_INVAL the format of the parameters was not valid
E_NOMEM not enough memory for allocating structures
E_BADF invalid oslDirectory parameter
E_INTR the function call was interrupted
- See Also
- open()
- reset
- RC reset();
-
| virtual |
abstract |
const |
volatile |
template |
static |
inline |
C-linkage |
| NO |
NO |
NO |
NO |
NO |
NO |
YES |
NO |
- Summary
- Resets the directory item enumeration to the beginning.
- Return
-
E_None on success
E_INVAL the format of the parameters was not valid
E_NOENT the specified path doesn't exist
E_NOTDIR the specified path is not an directory
E_NOMEM not enough memory for allocating structures
E_ACCES permission denied
E_MFILE too many open files used by the process
E_NFILE too many open files in the system
E_NAMETOOLONG File name too long
E_LOOP Too many symbolic links encountered
- See Also
- open()
- getNextItem
- RC getNextItem(
-
| virtual |
abstract |
const |
volatile |
template |
static |
inline |
C-linkage |
| NO |
NO |
NO |
NO |
NO |
NO |
YES |
NO |
- Summary
- Retrieve the next item of a previously opened directory.
- Description
- Retrieves the next item of a previously opened directory.
- Parameters
| rItem |
On success a valid DirectoryItem.
|
| nHint |
With this parameter the caller can tell the implementation that (s)he
is going to call this function uHint times afterwards. This enables the implementation to
get the information for more than one file and cache it until the next calls.
|
- Return
-
E_None on success
E_INVAL the format of the parameters was not valid
E_NOMEM not enough memory for allocating structures
E_NOENT no more entries in this directory
E_BADF invalid oslDirectory parameter
E_OVERFLOW the value too large for defined data type
- See Also
- DirectoryItem
- getVolumeInfo
- static RC getVolumeInfo(
-
| virtual |
abstract |
const |
volatile |
template |
static |
inline |
C-linkage |
| NO |
NO |
NO |
NO |
NO |
YES |
YES |
NO |
- Summary
- Retrieve information about a volume.
- Description
- Retrieves information about a volume. A volume can either be a mount point, a network
resource or a drive depending on Operating System and File System.
- Parameters
| ustrDirectoryURL |
Full qualified URL of the volume
|
| rInfo |
On success it receives information about the volume.
|
- Return
-
E_None on success
E_NOMEM not enough memory for allocating structures
E_INVAL the format of the parameters was not valid
E_NOTDIR not a directory
E_NAMETOOLONG file name too long
E_NOENT no such file or directory
E_ACCES permission denied
E_LOOP too many symbolic links encountered
E_FAULT Bad address
E_IO on I/O errors
E_NOSYS function not implemented
E_MULTIHOP multihop attempted
E_NOLINK link has been severed
E_INTR function call was interrupted
- See Also
- FileStatus
VolumeInfo
- create
- static RC create(
| const ::rtl::OUString & |
ustrDirectoryURL ); |
| virtual |
abstract |
const |
volatile |
template |
static |
inline |
C-linkage |
| NO |
NO |
NO |
NO |
NO |
YES |
YES |
NO |
- Summary
- Create a directory.
- Parameters
| ustrDirectoryURL |
Full qualified URL of the directory to create.
|
- Return
-
E_None on success
E_INVAL the format of the parameters was not valid
E_NOMEM not enough memory for allocating structures
E_EXIST file exists
E_ACCES permission denied
E_NAMETOOLONG file name too long
E_NOENT no such file or directory
E_NOTDIR not a directory
E_ROFS read-only file system
E_NOSPC no space left on device
E_DQUOT quota exceeded
E_LOOP too many symbolic links encountered
E_FAULT bad address
E_IO on I/O errors
E_MLINK too many links
E_MULTIHOP multihop attempted
E_NOLINK link has been severed
- See Also
- remove()
- remove
- static RC remove(
| const ::rtl::OUString & |
ustrDirectoryURL ); |
| virtual |
abstract |
const |
volatile |
template |
static |
inline |
C-linkage |
| NO |
NO |
NO |
NO |
NO |
YES |
YES |
NO |
- Summary
- Remove an empty directory.
- Parameters
| ustrDirectoryURL |
Full qualified URL of the directory.
|
- Return
-
E_None on success
E_INVAL the format of the parameters was not valid
E_NOMEM not enough memory for allocating structures
E_PERM operation not permitted
E_ACCES permission denied
E_NOENT no such file or directory
E_NOTDIR not a directory
E_NOTEMPTY directory not empty
E_FAULT bad address
E_NAMETOOLONG file name too long
E_BUSY device or resource busy
E_ROFS read-only file system
E_LOOP too many symbolic links encountered
E_BUSY device or resource busy
E_EXIST file exists
E_IO on I/O errors
E_MULTIHOP multihop attempted
E_NOLINK link has been severed
- See Also
- create()
- createPath
- static RC createPath(
-
| virtual |
abstract |
const |
volatile |
template |
static |
inline |
C-linkage |
| NO |
NO |
NO |
NO |
NO |
YES |
YES |
NO |
- Summary
- Create a directory path.
- Description
- The osl_createDirectoryPath function creates a specified directory path.
All nonexisting sub directories will be created.
PLEASE NOTE: You cannot rely on getting the error code
E_EXIST for existing directories. Programming against this error code is
in general a strong indication of a wrong usage of osl_createDirectoryPath.
- Parameters
| aDirectoryUrl |
[in] The absolute file URL of the directory path to create.
A relative file URL will not be accepted.
|
| aDirectoryCreationObserver |
[in] Pointer to an instance of type DirectoryCreationObserver that will
be informed about the creation of a directory. The value of this
parameter may be NULL, in this case notifications will not be sent.
|
- Return
-
- E_None
- On success
- E_INVAL
- The format of the parameters was not valid
- E_ACCES
- Permission denied
- E_EXIST
- The final node of the specified directory path already exist
- E_NAMETOOLONG
- The name of the specified directory path exceeds the maximum allowed length
- E_NOTDIR
- A component of the specified directory path already exist as file in any part of the directory path
- E_ROFS
- Read-only file system
- E_NOSPC
- No space left on device
- E_DQUOT
- Quota exceeded
- E_FAULT
- Bad address
- E_IO
- I/O error
- E_LOOP
- Too many symbolic links encountered
- E_NOLINK
- Link has been severed
- E_invalidError
- An unknown error occurred
- See Also
- DirectoryCreationObserver
create
Top of Page
Copyright © 2012, The Apache Software Foundation, Licensed under the Apache License, Version 2.0. Apache, the Apache feather logo, Apache OpenOffice and OpenOffice.org are trademarks of The Apache Software Foundation. Other names may be trademarks of their respective owners.


Ugrad Projects
Various undergraduate projects at SNU
Virtual 3D Volleyball (Computer Graphics, 2001)
- Was a team project with a teammate.
- Was an interactive 3D game.
- Converted 2D picatzu volley ball game into a 3D environment.
- Used the Open GL library and the Visual Studio 6.0 in a Windows platform.
Real Time Strategy Game for SnowBall Fight (Project 2, 2002)
- Was a team project with five other members.
- Was an interactive 3D game.
- Tried to implement Real-Time Strategy Game for snowball fight.
- Implemented direct selection in 3D environment.
- Implemented path-find algorithms and terrain map.
- Used the Open GL library and the Visual Studio 6.0 in a Windows platform.
Hexagoal Tortoise Problem Solving with Hybrid GAs (Genetic Algorithms, 2005)
- Is a basically NP-hard problem.
- Used Near-By-Search Algorithm(Modified 2-Opt) for local optimization.
- Solved the 110 size problem and Suggested the optimal solution.
- Tried the 182 size and Suggested the closest optimum.
Active Contour Model Demo (Digital Signal Processing, 2005)
- ACM is a new way of acquiring contour lines in a image.
- Was a team project with two other members.
- Implemented ACM algorithm based on a thesis, “On Active Contour Models and Balloons” by Laurent D. Cohen.
NACHOS Project (Operating System, 2001)
- Was a team project with two other members.
- Implemented the following features for the NACHOS OS.
- Synchronization
- Thread & Synchronization
- Virtual Memory
- System Call & Multi Programming
- File System
MIPS-like CPU Design using Xilinx Software (Computer System Design, 2001)
The main objective for the project was originally designing a serial communication module with FPGA.
- Was a team project with a teammate.
- Designed a simple MIPS-like CPU and its instruction set.
- Programmed an assembler for the designed instruction set.
- Used rewritable ROM to store the data.
- Was able to echo the serial communication with a PC.
- Used polling mechanism to read inputs from the serial controller.
Dance Dance Revolution with LCD arrays (Logic Design Lab, 2000)
- Was an interactive game on a circuit board.
- Used 5x10 LCD arrays to display game board.
- Used five push-button switches as an input method.
- Used VHDL with ABEL language.
- Used 64Kb ROM to store the game data.
Final Term Project “My memories” (Photography, 2002)
- BW photo development
- 8x11 inch size prints


 Moment Raheem Sterling's fiancée Paige Milian SHOVES woman out the way as she twerks against Man City star at his Great Gatsby-themed 25th birthday
by Sarah Packer For MailonlineRaheem Sterling's fiancée Paige Milian shoved a woman out of the way who was twerking against the Manchester City star at his 25th birthday.
The Premier League ace was seen on video enjoying an intimate dance with a glamorous party-goer, who was grinding her hips against him as he bent her over.
But their moment in the spotlight didn't last long as Paige quickly barged the woman aside so she could reclaim the rights to her man - and began twerking on him herself.
A party-goer told MailOnline: 'Paige saw the woman dancing with Raheem and marched straight over to intervene.
'It was all good-natured, but she was marking her territory and then she started twerking with her man.'
England star Sterling was celebrating turning 25 with a Great Gatsby-themed party in Manchester at the Hilton Hotel on Sunday night.
He posed for photographs on arrival with Paige, who wore a glitzy floor length gown while Sterling came dressed in a cream suit.
The footballer proposed to former shop assistant Paige in 2018 with the couple reportedly planning on getting married next year.
Paige gave birth to their son Thiago last year, and Sterling has a daughter, Melody Rose, from a previous relationship.
Raheem was joined at the party by a host of his fellow Man City stars including Brazilians Ederson, Fernandinho and Gabriel Jesus, English defenders John Stones and Kyle Walker and the club's new signing Rodri.
Before the festivities began, Sterling received a birthday message from Paige, who wrote on Instagram: 'HAPPY 25TH BIRTHDAYYYY BABE @sterling7 no need for a paragraph yuh done know how di ting go already. LOVE YOU MORE THAN YOU’LL EVER KNOW.'
She also shared a happy birthday message shared by his reps, Colossal Sports Management, and when inside the plush venue shared a sultry boomerang with another of the WAGS.
The Nike athlete took to his own account to share a scrap book made by one of his young fans.
The booklet, comprised of photos of the pair and important moments in the star's careers, was made by Charlotte Tyers - whom Raheem is close to.
The glitzy bash comes after disappointment in the Manchester Derby when Raheem and his teammates lost to rivals Manchester United.


Running Sage’s Doctests#
Doctesting a function ensures that the function performs as claimed by its documentation. Testing can be performed using one thread or multiple threads. After compiling a source version of Sage, doctesting can be run on the whole Sage library, on all modules under a given directory, or on a specified module only. For the purposes of this chapter, suppose we have compiled Sage from source and the top level directory is:
[jdemeyer@localhost sage]$ pwd
/home/jdemeyer/sage
See the section Running automated doctests for information on Sage’s automated testing process. The general syntax for doctesting is as follows. To doctest a module in the library of a version of Sage, use this syntax:
/path/to/sage-x.y.z/sage -t [--long] /path/to/sage-x.y.z/path/to/module.py[x]
where --long
is an optional argument (see Optional arguments
for more options). The version of sage
used must match the version
of Sage containing the module we want to doctest. A Sage module can be
either a Python script (with the file extension “.py”) or it can be a
Cython script, in which case it has the file extension “.pyx”.
Testing a module#
Say we want to run all tests in the sudoku module
sage/games/sudoku.py
. In a terminal window, first we cd
to the
top level Sage directory of our local Sage installation. Now we can
start doctesting as demonstrated in the following terminal session:
[jdemeyer@localhost sage]$ ./sage -t src/sage/games/sudoku.py
Running doctests with ID 2012-07-03-03-36-49-d82849c6.
Doctesting 1 file.
sage -t src/sage/games/sudoku.py
[103 tests, 3.6 s]
------------------------------------------------------------------------
All tests passed!
------------------------------------------------------------------------
Total time for all tests: 4.8 seconds
cpu time: 3.6 seconds
cumulative wall time: 3.6 seconds
The numbers output by the test show that testing the sudoku module takes about four seconds, while testing all specified modules took the same amount of time; the total time required includes some startup time for the code that runs the tests. In this case, we only tested one module so it is not surprising that the total testing time is approximately the same as the time required to test only that one module. Notice that the syntax is:
[jdemeyer@localhost sage]$ ./sage -t src/sage/games/sudoku.py
Running doctests with ID 2012-07-03-03-39-02-da6accbb.
Doctesting 1 file.
sage -t src/sage/games/sudoku.py
[103 tests, 3.6 s]
------------------------------------------------------------------------
All tests passed!
------------------------------------------------------------------------
Total time for all tests: 4.9 seconds
cpu time: 3.6 seconds
cumulative wall time: 3.6 seconds
but not:
[jdemeyer@localhost sage]$ ./sage -t sage/games/sudoku.py
Running doctests with ID 2012-07-03-03-40-53-6cc4f29f.
No files matching sage/games/sudoku.py
No files to doctest
We can also first cd
to the directory containing the module
sudoku.py
and doctest that module as follows:
[jdemeyer@localhost sage]$ cd src/sage/games/
[jdemeyer@localhost games]$ ls
__init__.py hexad.py sudoku.py sudoku_backtrack.pyx
all.py quantumino.py sudoku_backtrack.c
[jdemeyer@localhost games]$ ../../../../sage -t sudoku.py
Running doctests with ID 2012-07-03-03-41-39-95ebd2ff.
Doctesting 1 file.
sage -t sudoku.py
[103 tests, 3.6 s]
------------------------------------------------------------------------
All tests passed!
------------------------------------------------------------------------
Total time for all tests: 5.2 seconds
cpu time: 3.6 seconds
cumulative wall time: 3.6 seconds
In all of the above terminal sessions, we used a local installation of Sage to test its own modules. Even if we have a system-wide Sage installation, using that version to doctest the modules of a local installation is a recipe for confusion.
You can also run the Sage doctester as follows:
[jdemeyer@localhost sage]$ ./sage -tox -e doctest -- src/sage/games/sudoku.py
See Additional Development and Testing Tools for more information about tox.
Troubleshooting#
To doctest modules of a Sage installation, from a terminal window we
first cd
to the top level directory of that Sage installation,
otherwise known as the SAGE_ROOT
of that installation. When we
run tests, we use that particular Sage installation via the syntax
./sage
; notice the “dot-forward-slash” at the front of
sage
. This is a precaution against confusion that can arise when
our system has multiple Sage installations. For example, the following
syntax is acceptable because we explicitly specify the Sage
installation in the current SAGE_ROOT
:
[jdemeyer@localhost sage]$ ./sage -t src/sage/games/sudoku.py
Running doctests with ID 2012-07-03-03-43-24-a3449f54.
Doctesting 1 file.
sage -t src/sage/games/sudoku.py
[103 tests, 3.6 s]
------------------------------------------------------------------------
All tests passed!
------------------------------------------------------------------------
Total time for all tests: 4.9 seconds
cpu time: 3.6 seconds
cumulative wall time: 3.6 seconds
[jdemeyer@localhost sage]$ ./sage -t "src/sage/games/sudoku.py"
Running doctests with ID 2012-07-03-03-43-54-ac8ca007.
Doctesting 1 file.
sage -t src/sage/games/sudoku.py
[103 tests, 3.6 s]
------------------------------------------------------------------------
All tests passed!
------------------------------------------------------------------------
Total time for all tests: 4.9 seconds
cpu time: 3.6 seconds
cumulative wall time: 3.6 seconds
The following syntax is not recommended as we are using a system-wide Sage installation (if it exists):
[jdemeyer@localhost sage]$ sage -t src/sage/games/sudoku.py
sage -t "src/sage/games/sudoku.py"
**********************************************************************
File "/home/jdemeyer/sage/src/sage/games/sudoku.py", line 515:
sage: next(h.solve(algorithm='backtrack'))
Exception raised:
Traceback (most recent call last):
File "/usr/local/sage/local/bin/ncadoctest.py", line 1231, in run_one_test
self.run_one_example(test, example, filename, compileflags)
File "/usr/local/sage/local/bin/sagedoctest.py", line 38, in run_one_example
OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags)
File "/usr/local/sage/local/bin/ncadoctest.py", line 1172, in run_one_example
compileflags, 1) in test.globs
File "<doctest __main__.example_13[4]>", line 1, in <module>
next(h.solve(algorithm='backtrack'))###line 515:
sage: next(h.solve(algorithm='backtrack'))
File "/home/jdemeyer/.sage/tmp/sudoku.py", line 607, in solve
for soln in gen:
File "/home/jdemeyer/.sage/tmp/sudoku.py", line 719, in backtrack
from sudoku_backtrack import backtrack_all
ImportError: No module named sudoku_backtrack
**********************************************************************
[...more errors...]
2 items had failures:
4 of 15 in __main__.example_13
2 of 8 in __main__.example_14
***Test Failed*** 6 failures.
For whitespace errors, see the file /home/jdemeyer/.sage//tmp/.doctest_sudoku.py
[21.1 s]
----------------------------------------------------------------------
The following tests failed:
sage -t "src/sage/games/sudoku.py"
Total time for all tests: 21.3 seconds
In this case, we received an error because the system-wide Sage installation is a different (older) version than the one we are using for Sage development. Make sure you always test the files with the correct version of Sage.
Parallel testing many modules#
So far we have used a single thread to doctest a module in the Sage library. There are hundreds, even thousands of modules in the Sage library. Testing them all using one thread would take a few hours. Depending on our hardware, this could take up to six hours or more. On a multi-core system, parallel doctesting can significantly reduce the testing time. Unless we also want to use our computer while doctesting in parallel, we can choose to devote all the cores of our system for parallel testing.
Let us doctest all modules in a directory, first using a single thread
and then using four threads. For this example, suppose we want to test
all the modules under sage/crypto/
. We can use a syntax similar to
that shown above to achieve this:
[jdemeyer@localhost sage]$ ./sage -t src/sage/crypto
Running doctests with ID 2012-07-03-03-45-40-7f837dcf.

------------------------------------------------------------------------
Total time for all tests: 38.1 seconds
cpu time: 29.8 seconds
cumulative wall time: 35.1 seconds
Now we do the same thing, but this time we also use the optional
argument --long
:
[jdemeyer@localhost sage]$ ./sage -t --long src/sage/crypto/
Running doctests with ID 2012-07-03-03-48-11-c16721e6.

------------------------------------------------------------------------
Total time for all tests: 111.8 seconds
cpu time: 106.1 seconds
cumulative wall time: 108.5 seconds
Notice the time difference between the first set of tests and the
second set, which uses the optional argument --long
. Many tests in the
Sage library are flagged with # long time
because these are known to
take a long time to run through. Without using the optional --long
argument, the module sage/crypto/mq/sr.py
took about five
seconds. With this optional argument, it required 82 seconds to run
through all tests in that module. Here is a snippet of a function in
the module sage/crypto/mq/sr.py
with a doctest that has been flagged
as taking a long time:
def test_consistency(max_n=2, **kwargs):
r"""
Test all combinations of ``r``, ``c``, ``e`` and ``n`` in ``(1,
2)`` for consistency of random encryptions and their polynomial
systems. `\GF{2}` and `\GF{2^e}` systems are tested. This test takes
a while.
INPUT:
- ``max_n`` -- maximal number of rounds to consider (default: 2)
- ``kwargs`` -- are passed to the SR constructor
TESTS:
The following test called with ``max_n`` = 2 requires a LOT of RAM
(much more than 2GB). Since this might cause the doctest to fail
on machines with "only" 2GB of RAM, we test ``max_n`` = 1, which
has a more reasonable memory usage. ::
sage: from sage.crypto.mq.sr import test_consistency
sage: test_consistency(1) # long time (80s on sage.math, 2011)
True
"""
Now we doctest the same directory in parallel using 4 threads:
[jdemeyer@localhost sage]$ ./sage -tp 4 src/sage/crypto/
Running doctests with ID 2012-07-07-00-11-55-9b17765e.
Sorting sources by runtime so that slower doctests are run first....

------------------------------------------------------------------------
Total time for all tests: 12.9 seconds
cpu time: 30.5 seconds
cumulative wall time: 31.7 seconds
[jdemeyer@localhost sage]$ ./sage -tp 4 --long src/sage/crypto/
Running doctests with ID 2012-07-07-00-13-04-d71f3cd4.
Sorting sources by runtime so that slower doctests are run first....

------------------------------------------------------------------------
Total time for all tests: 90.4 seconds
cpu time: 113.4 seconds
cumulative wall time: 114.5 seconds
As the number of threads increases, the total testing time decreases.
Parallel testing the whole Sage library#
The main Sage library resides in the directory
SAGE_ROOT/src/
. We can use the syntax described above
to doctest the main library using multiple threads. When doing release
management or patching the main Sage library, a release manager would
parallel test the library using 10 threads with the following command:
[jdemeyer@localhost sage]$ ./sage -tp 10 --long src/
Another way is run make ptestlong
, which builds Sage (if necessary),
builds the Sage documentation (if necessary), and then runs parallel
doctests. This determines the number of threads by reading the
environment variable MAKE
: if it is set to make -j12
, then
use 12 threads. If MAKE
is not set, then by default it uses
the number of CPU cores (as determined by the Python function
multiprocessing.cpu_count()
) with a minimum of 2 and a maximum of 8.
In any case, this will test the Sage library with multiple threads:
[jdemeyer@localhost sage]$ make ptestlong
Any of the following commands would also doctest the Sage library or one of its clones:
make test
make check
make testlong
make ptest
make ptestlong
The differences are:
make test
andmake check
— These two commands run the same set of tests. First the Sage standard documentation is tested, i.e. the documentation that resides inSAGE_ROOT/src/doc/common
SAGE_ROOT/src/doc/en
SAGE_ROOT/src/doc/fr
Finally, the commands doctest the Sage library. For more details on these command, see the file
SAGE_ROOT/Makefile
.make testlong
— This command doctests the standard documentation:SAGE_ROOT/src/doc/common
SAGE_ROOT/src/doc/en
SAGE_ROOT/src/doc/fr
and then the Sage library. Doctesting is run with the optional argument
--long
. See the fileSAGE_ROOT/Makefile
for further details.make ptest
— Similar to the commandsmake test
andmake check
. However, doctesting is run with the number of threads as described above formake ptestlong
.make ptestlong
— Similar to the commandmake ptest
, but using the optional argument--long
for doctesting.
The underlying command for running these tests is sage -t --all
. For
example, make ptestlong
executes the command
sage -t -p --all --long --logfile=logs/ptestlong.log
. So if you want
to add extra flags when you run these tests, for example --verbose
,
you can execute
sage -t -p --all --long --verbose --logfile=path/to/logfile
.
Some of the extra testing options are discussed here; run
sage -t -h
for a complete list.
Beyond the Sage library#
Doctesting also works fine for files not in the Sage library. For
example, suppose we have a Python script called
my_python_script.py
:
[mvngu@localhost sage]$ cat my_python_script.py
from sage.all_cmdline import * # import sage library
def square(n):
"""
Return the square of n.
EXAMPLES::
sage: square(2)
4
"""
return n**2
Then we can doctest it just as with Sage library files:
[mvngu@localhost sage]$ ./sage -t my_python_script.py
Running doctests with ID 2012-07-07-00-17-56-d056f7c0.
Doctesting 1 file.
sage -t my_python_script.py
[1 test, 0.0 s]
------------------------------------------------------------------------
All tests passed!
------------------------------------------------------------------------
Total time for all tests: 2.2 seconds
cpu time: 0.0 seconds
cumulative wall time: 0.0 seconds
Doctesting can also be performed on Sage scripts. Say we have a Sage
script called my_sage_script.sage
with the following content:
[mvngu@localhost sage]$ cat my_sage_script.sage
def cube(n):
r"""
Return the cube of n.
EXAMPLES::
sage: cube(2)
8
"""
return n**3
Then we can doctest it just as for Python files:
[mvngu@localhost sage]$ ./sage -t my_sage_script.sage
Running doctests with ID 2012-07-07-00-20-06-82ee728c.
Doctesting 1 file.
sage -t my_sage_script.sage
[1 test, 0.0 s]
------------------------------------------------------------------------
All tests passed!
------------------------------------------------------------------------
Total time for all tests: 2.5 seconds
cpu time: 0.0 seconds
cumulative wall time: 0.0 seconds
Alternatively, we can preparse it to convert it to a Python script, and then doctest that:
[mvngu@localhost sage]$ ./sage --preparse my_sage_script.sage
[mvngu@localhost sage]$ cat my_sage_script.sage.py
# This file was *autogenerated* from the file my_sage_script.sage.
from sage.all_cmdline import * # import sage library
_sage_const_3 = Integer(3)
def cube(n):
r"""
Return the cube of n.
EXAMPLES::
sage: cube(2)
8
"""
return n**_sage_const_3
[mvngu@localhost sage]$ ./sage -t my_sage_script.sage.py
Running doctests with ID 2012-07-07-00-26-46-2bb00911.
Doctesting 1 file.
sage -t my_sage_script.sage.py
[2 tests, 0.0 s]
------------------------------------------------------------------------
All tests passed!
------------------------------------------------------------------------
Total time for all tests: 2.3 seconds
cpu time: 0.0 seconds
cumulative wall time: 0.0 seconds
Doctesting from within Sage#
You can run doctests from within Sage, which can be useful since you
don’t have to wait for Sage to start. Use the run_doctests
function in the global namespace, passing it either a string or a module:
sage: run_doctests(sage.combinat.affine_permutation)
Running doctests with ID 2018-02-07-13-23-13-89fe17b1.
Git branch: develop
Using --optional=sagemath_doc_html,sage
Doctesting 1 file.
sage -t /opt/sage/sage_stable/src/sage/combinat/affine_permutation.py
[338 tests, 4.32 s]
----------------------------------------------------------------------
All tests passed!
----------------------------------------------------------------------
Total time for all tests: 4.4 seconds
cpu time: 3.6 seconds
cumulative wall time: 4.3 seconds
Optional arguments#
Run long doctests#
Ideally, doctests should not take any noticeable amount of time. If you really need longer-running doctests (anything beyond about one second) then you should mark them as:
sage: my_long_test() # long time
Even then, long doctests should ideally complete in 5 seconds or less. We know that you (the author) want to show off the capabilities of your code, but this is not the place to do so. Long-running tests will sooner or later hurt our ability to run the testsuite. Really, doctests should be as fast as possible while providing coverage for the code.
Use the --long
flag to run doctests that have been marked with the
comment # long time
. These tests are normally skipped in order to
reduce the time spent running tests:
[roed@localhost sage]$ ./sage -t src/sage/rings/tests.py
Running doctests with ID 2012-06-21-16-00-13-40835825.
Doctesting 1 file.
sage -t tests.py
[18 tests, 1.1 s]
------------------------------------------------------------------------
All tests passed!
------------------------------------------------------------------------
Total time for all tests: 2.9 seconds
cpu time: 0.9 seconds
cumulative wall time: 1.1 seconds
In order to run the long tests as well, do the following:
[roed@localhost sage]$ ./sage -t --long src/sage/rings/tests.py
Running doctests with ID 2012-06-21-16-02-05-d13a9a24.
Doctesting 1 file.
sage -t tests.py
[20 tests, 34.7 s]
------------------------------------------------------------------------
All tests passed!
------------------------------------------------------------------------
Total time for all tests: 46.5 seconds
cpu time: 25.2 seconds
cumulative wall time: 34.7 seconds
To find tests that take longer than the allowed time use the
--warn-long
flag. Without any options it will cause tests to
print a warning if they take longer than 1.0 second. Note that this is
a warning, not an error:
[roed@localhost sage]$ ./sage -t --warn-long src/sage/rings/factorint.pyx
Running doctests with ID 2012-07-14-03-27-03-2c952ac1.
Doctesting 1 file.
sage -t --warn-long src/sage/rings/factorint.pyx
**********************************************************************
File "src/sage/rings/factorint.pyx", line 125, in sage.rings.factorint.base_exponent
Failed example:
base_exponent(-4)
Test ran for 4.09 s
**********************************************************************
File "src/sage/rings/factorint.pyx", line 153, in sage.rings.factorint.factor_aurifeuillian
Failed example:
fa(2^6+1)
Test ran for 2.22 s
**********************************************************************
File "src/sage/rings/factorint.pyx", line 155, in sage.rings.factorint.factor_aurifeuillian
Failed example:
fa(2^58+1)
Test ran for 2.22 s
**********************************************************************
File "src/sage/rings/factorint.pyx", line 163, in sage.rings.factorint.factor_aurifeuillian
Failed example:
fa(2^4+1)
Test ran for 2.25 s
**********************************************************************
----------------------------------------------------------------------
All tests passed!
----------------------------------------------------------------------
Total time for all tests: 16.1 seconds
cpu time: 9.7 seconds
cumulative wall time: 10.9 seconds
You can also pass in an explicit amount of time:
[roed@localhost sage]$ ./sage -t --long --warn-long 2.0 src/sage/rings/tests.py
Running doctests with ID 2012-07-14-03-30-13-c9164c9d.
Doctesting 1 file.
sage -t --long --warn-long 2.0 tests.py
**********************************************************************
File "tests.py", line 240, in sage.rings.tests.test_random_elements
Failed example:
sage.rings.tests.test_random_elements(trials=1000) # long time (5 seconds)
Test ran for 13.36 s
**********************************************************************
File "tests.py", line 283, in sage.rings.tests.test_random_arith
Failed example:
sage.rings.tests.test_random_arith(trials=1000) # long time (5 seconds?)
Test ran for 12.42 s
**********************************************************************
----------------------------------------------------------------------
All tests passed!
----------------------------------------------------------------------
Total time for all tests: 27.6 seconds
cpu time: 24.8 seconds
cumulative wall time: 26.3 seconds
Finally, you can disable any warnings about long tests with
--warn-long 0
.
Doctests start from a random seed:
[kliem@localhost sage]$ ./sage -t src/sage/doctest/tests/random_seed.rst
Running doctests with ID 2020-06-23-23-22-59-49f37a55.
...
Doctesting 1 file.
sage -t --warn-long 89.5 --random-seed=112986622569797306072457879734474628454 src/sage/doctest/tests/random_seed.rst
**********************************************************************
File "src/sage/doctest/tests/random_seed.rst", line 3, in sage.doctest.tests.random_seed
Failed example:
randint(5, 10)
Expected:
9
Got:
8
**********************************************************************
1 item had failures:
1 of 2 in sage.doctest.tests.random_seed
[1 test, 1 failure, 0.00 s]
----------------------------------------------------------------------
sage -t --warn-long 89.5 --random-seed=112986622569797306072457879734474628454 src/sage/doctest/tests/random_seed.rst # 1 doctest failed
----------------------------------------------------------------------
Total time for all tests: 0.0 seconds
cpu time: 0.0 seconds
cumulative wall time: 0.0 seconds
This seed can be set explicitly to reproduce possible failures:
[kliem@localhost sage]$ ./sage -t --warn-long 89.5 \
--random-seed=112986622569797306072457879734474628454 \
src/sage/doctest/tests/random_seed.rst
Running doctests with ID 2020-06-23-23-24-28-14a52269.
...
Doctesting 1 file.
sage -t --warn-long 89.5 --random-seed=112986622569797306072457879734474628454 src/sage/doctest/tests/random_seed.rst
**********************************************************************
File "src/sage/doctest/tests/random_seed.rst", line 3, in sage.doctest.tests.random_seed
Failed example:
randint(5, 10)
Expected:
9
Got:
8
**********************************************************************
1 item had failures:
1 of 2 in sage.doctest.tests.random_seed
[1 test, 1 failure, 0.00 s]
----------------------------------------------------------------------
sage -t --warn-long 89.5 --random-seed=112986622569797306072457879734474628454 src/sage/doctest/tests/random_seed.rst # 1 doctest failed
----------------------------------------------------------------------
Total time for all tests: 0.0 seconds
cpu time: 0.0 seconds
cumulative wall time: 0.0 seconds
It can also be set explicitly using the environment variable
SAGE_DOCTEST_RANDOM_SEED
.
Run optional doctests#
You can run tests that require optional packages by using the
--optional
flag. Obviously, you need to have installed the
necessary optional packages in order for these tests to succeed.
By default, Sage only runs doctests that are not marked with the optional
tag. This is equivalent to running
[roed@localhost sage]$ ./sage -t --optional=sagemath_doc_html,sage \
src/sage/rings/real_mpfr.pyx
Running doctests with ID 2012-06-21-16-18-30-a368a200.
Doctesting 1 file.
sage -t src/sage/rings/real_mpfr.pyx
[819 tests, 7.0 s]
------------------------------------------------------------------------
All tests passed!
------------------------------------------------------------------------
Total time for all tests: 8.4 seconds
cpu time: 4.1 seconds
cumulative wall time: 7.0 seconds
If you want to also run tests that require magma, you can do the following:
[roed@localhost sage]$ ./sage -t --optional=sagemath_doc_html,sage,magma \
src/sage/rings/real_mpfr.pyx
Running doctests with ID 2012-06-21-16-18-30-a00a7319
Doctesting 1 file.
sage -t src/sage/rings/real_mpfr.pyx
[823 tests, 8.4 s]
------------------------------------------------------------------------
All tests passed!
------------------------------------------------------------------------
Total time for all tests: 9.6 seconds
cpu time: 4.0 seconds
cumulative wall time: 8.4 seconds
In order to just run the tests that are marked as requiring magma, omit sage
and sagemath_doc_html
:
[roed@localhost sage]$ ./sage -t --optional=magma src/sage/rings/real_mpfr.pyx
Running doctests with ID 2012-06-21-16-18-33-a2bc1fdf
Doctesting 1 file.
sage -t src/sage/rings/real_mpfr.pyx
[4 tests, 2.0 s]
------------------------------------------------------------------------
All tests passed!
------------------------------------------------------------------------
Total time for all tests: 3.2 seconds
cpu time: 0.1 seconds
cumulative wall time: 2.0 seconds
If you want Sage to detect external software or other capabilities
(such as magma, latex, internet) automatically and run all of the
relevant tests, then add external
:
[roed@localhost sage]$ ./sage -t --optional=external src/sage/rings/real_mpfr.pyx
Running doctests with ID 2016-03-16-14-10-21-af2ebb67.
Using --optional=external
External software to be detected: cplex,gurobi,internet,latex,macaulay2,magma,maple,mathematica,matlab,octave,scilab
Doctesting 1 file.
sage -t --warn-long 28.0 src/sage/rings/real_mpfr.pyx
[5 tests, 0.04 s]
----------------------------------------------------------------------
All tests passed!
----------------------------------------------------------------------
Total time for all tests: 0.5 seconds
cpu time: 0.0 seconds
cumulative wall time: 0.0 seconds
External software detected for doctesting: magma
To run all tests, regardless of whether they are marked optional, pass all
as the optional
tag:
[roed@localhost sage]$ ./sage -t --optional=all src/sage/rings/real_mpfr.pyx
Running doctests with ID 2012-06-21-16-31-18-8c097f55
Doctesting 1 file.
sage -t src/sage/rings/real_mpfr.pyx
[865 tests, 11.2 s]
------------------------------------------------------------------------
All tests passed!
------------------------------------------------------------------------
Total time for all tests: 12.8 seconds
cpu time: 4.7 seconds
cumulative wall time: 11.2 seconds
Running doctests in parallel#
If you’re testing many files, you can get big speedups by using more
than one thread. To run doctests in parallel use the --nthreads
flag (-p
is a shortened version). Pass in the number of threads
you would like to use (by default Sage just uses 1):
[roed@localhost sage]$ ./sage -tp 2 src/sage/doctest/
Running doctests with ID 2012-06-22-19-09-25-a3afdb8c.
Sorting sources by runtime so that slower doctests are run first....
Doctesting 8 files using 2 threads.
sage -t src/sage/doctest/control.py
[114 tests, 4.6 s]
sage -t src/sage/doctest/util.py
[114 tests, 0.6 s]
sage -t src/sage/doctest/parsing.py
[187 tests, 0.5 s]
sage -t src/sage/doctest/sources.py
[128 tests, 0.1 s]
sage -t src/sage/doctest/reporting.py
[53 tests, 0.1 s]
sage -t src/sage/doctest/all.py
[0 tests, 0.0 s]
sage -t src/sage/doctest/__init__.py
[0 tests, 0.0 s]
sage -t src/sage/doctest/forker.py
[322 tests, 15.5 s]
------------------------------------------------------------------------
All tests passed!
------------------------------------------------------------------------
Total time for all tests: 17.0 seconds
cpu time: 4.2 seconds
cumulative wall time: 21.5 seconds
Doctesting all of Sage#
To doctest the whole Sage library use the --all
flag (-a
for
short). In addition to testing the code in Sage’s Python and Cython
files, this command will run the tests defined in Sage’s documentation
as well as testing the Sage notebook:
[roed@localhost sage]$ ./sage -t -a
Running doctests with ID 2012-06-22-19-10-27-e26fce6d.
Doctesting entire Sage library.
Sorting sources by runtime so that slower doctests are run first....
Doctesting 2020 files.
sage -t /Users/roed/sage/src/sage/plot/plot.py
[304 tests, 69.0 s]
...
Debugging tools#
Sometimes doctests fail (that’s why we run them after all). There are
various flags to help when something goes wrong. If a doctest
produces a Python error, then normally tests continue after reporting
that an error occurred. If you use the flag --debug
(-d
for
short) then you will drop into an interactive Python debugger whenever
a Python exception occurs. As an example, I modified
sage.schemes.elliptic_curves.constructor
to produce an error:
[roed@localhost sage]$ ./sage -t --debug \
src/sage/schemes/elliptic_curves/constructor.py
Running doctests with ID 2012-06-23-12-09-04-b6352629.
Doctesting 1 file.
**********************************************************************
File "sage.schemes.elliptic_curves.constructor", line 4, in sage.schemes.elliptic_curves.constructor
Failed example:
EllipticCurve([0,0])
Exception raised:
Traceback (most recent call last):
File ".../site-packages/sage/doctest/forker.py", line 573, in _run
self.execute(example, compiled, test.globs)
File ".../site-packages/sage/doctest/forker.py", line 835, in execute
exec compiled in globs
File "<doctest sage.schemes.elliptic_curves.constructor[0]>", line 1, in <module>
EllipticCurve([Integer(0),Integer(0)])
File ".../site-packages/sage/schemes/elliptic_curves/constructor.py", line 346, in EllipticCurve
return ell_rational_field.EllipticCurve_rational_field(x, y)
File ".../site-packages/sage/schemes/elliptic_curves/ell_rational_field.py", line 216, in __init__
EllipticCurve_number_field.__init__(self, Q, ainvs)
File ".../site-packages/sage/schemes/elliptic_curves/ell_number_field.py", line 159, in __init__
EllipticCurve_field.__init__(self, [field(x) for x in ainvs])
File ".../site-packages/sage/schemes/elliptic_curves/ell_generic.py", line 156, in __init__
"Invariants %s define a singular curve."%ainvs
ArithmeticError: Invariants [0, 0, 0, 0, 0] define a singular curve.
> .../site-packages/sage/schemes/elliptic_curves/ell_generic.py(156)__init__()
-> "Invariants %s define a singular curve."%ainvs
(Pdb) l
151 if len(ainvs) == 2:
152 ainvs = [K(0),K(0),K(0)] + ainvs
153 self.__ainvs = tuple(ainvs)
154 if self.discriminant() == 0:
155 raise ArithmeticError(
156 -> "Invariants %s define a singular curve."%ainvs)
157 PP = projective_space.ProjectiveSpace(2, K, names='xyz');
158 x, y, z = PP.coordinate_ring().gens()
159 a1, a2, a3, a4, a6 = ainvs
160 f = y**2*z + (a1*x + a3*z)*y*z \
161 - (x**3 + a2*x**2*z + a4*x*z**2 + a6*z**3)
(Pdb) p ainvs
[0, 0, 0, 0, 0]
(Pdb) quit
**********************************************************************
1 items had failures:
1 of 1 in sage.schemes.elliptic_curves.constructor
***Test Failed*** 1 failures.
sage -t src/sage/schemes/elliptic_curves/constructor.py
[64 tests, 89.2 s]
------------------------------------------------------------------------
sage -t src/sage/schemes/elliptic_curves/constructor.py # 1 doctest failed
------------------------------------------------------------------------
Total time for all tests: 90.4 seconds
cpu time: 4.5 seconds
cumulative wall time: 89.2 seconds
Sometimes an error might be so severe that it causes Sage to segfault
or hang. In such a situation you have a number of options. The
doctest framework will print out the output so far, so that at least
you know what test caused the problem (if you want this output to
appear in real time use the --verbose
flag). To have doctests run
under the control of gdb, use the --gdb
flag:
[roed@localhost sage]$ ./sage -t --gdb \
src/sage/schemes/elliptic_curves/constructor.py
exec gdb --eval-commands="run" --args /home/roed/sage/local/var/lib/sage/venv-python3.9/bin/python3 sage-runtests --serial --timeout=0 --stats_path=/home/roed/.sage/timings2.json --optional=pip,sage,sage_spkg src/sage/schemes/elliptic_curves/constructor.py
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...
[Thread debugging using libthread_db enabled]
[New Thread 0x7f10f85566e0 (LWP 6534)]
Running doctests with ID 2012-07-07-00-43-36-b1b735e7.
Doctesting 1 file.
sage -t src/sage/schemes/elliptic_curves/constructor.py
[67 tests, 5.8 s]
------------------------------------------------------------------------
All tests passed!
------------------------------------------------------------------------
Total time for all tests: 15.7 seconds
cpu time: 4.4 seconds
cumulative wall time: 5.8 seconds
Program exited normally.
(gdb) quit
Sage also includes valgrind, and you can run doctests under various
valgrind tools to track down memory issues: the relevant flags are
--valgrind
(or --memcheck
), --massif
, --cachegrind
and
--omega
. See http://wiki.sagemath.org/ValgrindingSage for more details.
Once you’re done fixing whatever problems where revealed by the
doctests, you can rerun just those files that failed their most recent
test by using the --failed
flag (-f
for short):
[roed@localhost sage]$ ./sage -t -fa
Running doctests with ID 2012-07-07-00-45-35-d8b5a408.
Doctesting entire Sage library.
Only doctesting files that failed last test.
No files to doctest
Miscellaneous options#
There are various other options that change the behavior of Sage’s doctesting code.
Show only first failure#
The first failure in a file often causes a cascade of others, as
NameErrors arise from variables that weren’t defined and tests fail
because old values of variables are used. To only see the first
failure in each doctest block use the --initial
flag (-i
for
short).
Show skipped optional tests#
To print a summary at the end of each file with the number of optional
tests skipped, use the --show-skipped
flag:
[roed@localhost sage]$ ./sage -t --show-skipped \
src/sage/rings/finite_rings/integer_mod.pyx
Running doctests with ID 2013-03-14-15-32-05-8136f5e3.

----------------------------------------------------------------------
Total time for all tests: 4.3 seconds
cpu time: 2.4 seconds
cumulative wall time: 4.0 seconds
Running tests with iterations#
Sometimes tests fail intermittently. There are two options that allow
you to run tests repeatedly in an attempt to search for Heisenbugs.
The flag --global-iterations
takes an integer and runs the whole
set of tests that many times serially:
[roed@localhost sage]$ ./sage -t --global-iterations 2 src/sage/sandpiles
Running doctests with ID 2012-07-07-00-59-28-e7048ad9.
Doctesting 3 files (2 global iterations).
sage -t src/sage/sandpiles/__init__.py
[0 tests, 0.0 s]
sage -t src/sage/sandpiles/all.py
[0 tests, 0.0 s]
sage -t src/sage/sandpiles/sandpile.py
[711 tests, 14.7 s]
------------------------------------------------------------------------
All tests passed!
------------------------------------------------------------------------
Total time for all tests: 17.6 seconds
cpu time: 13.2 seconds
cumulative wall time: 14.7 seconds
sage -t src/sage/sandpiles/__init__.py
[0 tests, 0.0 s]
sage -t src/sage/sandpiles/all.py
[0 tests, 0.0 s]
sage -t src/sage/sandpiles/sandpile.py
[711 tests, 13.8 s]
------------------------------------------------------------------------
All tests passed!
------------------------------------------------------------------------
Total time for all tests: 14.3 seconds
cpu time: 26.4 seconds
cumulative wall time: 28.5 seconds
You can also iterate in a different order: the --file-iterations
flag runs the tests in each file N
times before proceeding:
[roed@localhost sage]$ ./sage -t --file-iterations 2 src/sage/sandpiles
Running doctests with ID 2012-07-07-01-01-43-8f954206.
Doctesting 3 files (2 file iterations).
sage -t src/sage/sandpiles/__init__.py
[0 tests, 0.0 s]
sage -t src/sage/sandpiles/all.py
[0 tests, 0.0 s]
sage -t src/sage/sandpiles/sandpile.py
[1422 tests, 13.3 s]
------------------------------------------------------------------------
All tests passed!
------------------------------------------------------------------------
Total time for all tests: 29.6 seconds
cpu time: 12.7 seconds
cumulative wall time: 13.3 seconds
Note that the reported results are the average time for all tests in that file to finish. If a failure in a file occurs, then the failure is reported and testing proceeds with the next file.
Using a different timeout#
On a slow machine the default timeout of 5 minutes may not be enough
for the slowest files. Use the --timeout
flag (-T
for short)
to set it to something else:
[roed@localhost sage]$ ./sage -tp 2 --all --timeout 1
Running doctests with ID 2012-07-07-01-09-37-deb1ab83.
Doctesting entire Sage library.
Sorting sources by runtime so that slower doctests are run first....
Doctesting 2067 files using 2 threads.
sage -t src/sage/schemes/elliptic_curves/ell_rational_field.py
Timed out!
...
Using absolute paths#
By default filenames are printed using relative paths. To use
absolute paths instead pass in the --abspath
flag:
[roed@localhost sage]$ ./sage -t --abspath src/sage/doctest/control.py
Running doctests with ID 2012-07-07-01-13-03-a023e212.
Doctesting 1 file.
sage -t /home/roed/sage/src/sage/doctest/control.py
[133 tests, 4.7 s]
------------------------------------------------------------------------
All tests passed!
------------------------------------------------------------------------
Total time for all tests: 7.1 seconds
cpu time: 0.2 seconds
cumulative wall time: 4.7 seconds
Testing changed files#
If you are working on some files in the Sage library it can be
convenient to test only the files that have changed. To do so use the
--new
flag, which tests files that have been modified or added
since the last commit:
[roed@localhost sage]$ ./sage -t --new
Running doctests with ID 2012-07-07-01-15-52-645620ee.
Doctesting files changed since last git commit.
Doctesting 1 file.
sage -t src/sage/doctest/control.py
[133 tests, 3.7 s]
------------------------------------------------------------------------
All tests passed!
------------------------------------------------------------------------
Total time for all tests: 3.8 seconds
cpu time: 0.1 seconds
cumulative wall time: 3.7 seconds
Running tests in a random order#
By default, tests are run in the order in which they appear in the
file. To run tests in a random order (which can reveal subtle bugs),
use the --randorder
flag and pass in a random seed:
[roed@localhost sage]$ ./sage -t --new --randorder 127
Running doctests with ID 2012-07-07-01-19-06-97c8484e.
Doctesting files changed since last git commit.
Doctesting 1 file.
sage -t src/sage/doctest/control.py
[133 tests, 3.6 s]
------------------------------------------------------------------------
All tests passed!
------------------------------------------------------------------------
Total time for all tests: 3.7 seconds
cpu time: 0.2 seconds
cumulative wall time: 3.6 seconds
Note that even with this option, the tests within a given doctest block are still run in order.
Testing external files#
When testing a file which is not part of a package (which is not in a
directory containing an __init__.py
file), the testing
code loads the globals from that file into the namespace before
running tests. To disable this behaviour (and require imports to be
explicitly specified), use the --force-lib
option.
Auxiliary files#
To specify a logfile (rather than use the default which is created for
sage -t --all
), use the --logfile
flag:
[roed@localhost sage]$ ./sage -t --logfile test1.log src/sage/doctest/control.py
Running doctests with ID 2012-07-07-01-25-49-e7c0e52d.
Doctesting 1 file.
sage -t src/sage/doctest/control.py
[133 tests, 4.3 s]
------------------------------------------------------------------------
All tests passed!
------------------------------------------------------------------------
Total time for all tests: 6.7 seconds
cpu time: 0.1 seconds
cumulative wall time: 4.3 seconds
[roed@localhost sage]$ cat test1.log
Running doctests with ID 2012-07-07-01-25-49-e7c0e52d.
Doctesting 1 file.
sage -t src/sage/doctest/control.py
[133 tests, 4.3 s]
------------------------------------------------------------------------
All tests passed!
 These statistics are used in sorting files so
that slower tests are run first (and thus multiple processes are
utilized most efficiently):
[roed@localhost sage]$ ./sage -tp 2 --stats-path ~/.sage/timings2.json --all
Running doctests with ID 2012-07-07-01-28-34-2df4251d.
Doctesting entire Sage library.
Sorting sources by runtime so that slower doctests are run first....
Doctesting 2067 files using 2 threads.
...
Options for testing in virtual environments#
The distribution packages of the modularized Sage library can be tested in virtual environments.
Sage has infrastructure to create such virtual environments using tox
, which is explained
in detail in Testing distribution packages. Our examples in this section
refer to this setting, but it applies the same to any user-created virtual environments.
The virtual environments, set up in directories such as
pkgs/sagemath-standard/.tox/sagepython-sagewheels-nopypi-norequirements
contain installations of built (non-editable) wheels.
To test all modules of Sage that are installed in a virtual environment,
use the option --installed
(instead of --all
):
[mkoeppe@localhost sage]$ pkgs/sagemath-standard/.tox/sagepython-.../sage -t \
-p4 --installed
This tests against the doctests as they appear in the installed copies of the files
(in site-packages/sage/...
).
Note that these installed copies should never be edited, as they can
be overwritten without warning.
When testing a modularized distribution package other than sagemath-standard,
the top-level module sage.all
is not available. Use the option --environment
to select an appropriate top-level module:
[mkoeppe@localhost sage]$ pkgs/sagemath-categories/.tox/sagepython-.../sage -t \
-p4 --environment sage.all__sagemath_categories \
--installed
To test the installed modules against the doctests as they appear in the source
tree (src/sage/...
):
[mkoeppe@localhost sage]$ pkgs/sagemath-categories/.tox/sagepython-.../sage -t \
-p4 --environment sage.all__sagemath_categories \
src/sage/structure
Note that testing all doctests as they appear in the source tree does not make sense
because many of the source files may not be installed in the virtual environment.
Use the option --if-installed
to skip the source files of all Python/Cython modules
that are not installed in the virtual environment:
[mkoeppe@localhost sage]$ pkgs/sagemath-categories/.tox/sagepython-.../sage -t \
-p4 --environment sage.all__sagemath_categories \
--if-installed src/sage/schemes
This option can also be combined with --all
:
[mkoeppe@localhost sage]$ pkgs/sagemath-categories/.tox/sagepython-.../sage -t \
-p4 --environment sage.all__sagemath_categories \
--if-installed --all
The doctest fixer#
Sage provides a development tool that assists with updating doctests.
Updating doctest outputs#
By default, ./sage --fixdoctests
runs the doctester and replaces the expected outputs
of all examples by the actual outputs from the current version of Sage:
[mkoeppe@localhost sage]$ ./sage --fixdoctests \
--overwrite src/sage/arith/weird.py
For example, when applied to this Python file:
| r"""
| ...
|
| EXAMPLES::
|
| sage: 2 + 2
| 5
| sage: factor("91")
| "7" * "13"
| ...
the doctest fixer edits the file as follows:
| r"""
| ...
|
| EXAMPLES::
|
| sage: 2 + 2
| 4
| sage: factor("91")
| Traceback (most recent call last):
| ...
| TypeError: unable to factor '91'
| ...
As this command edits the source file, it may be a good practice to first use git commit
to save any changes made in the file.
After running the doctest fixer, it is a good idea to use git diff
to check
all edits that the automated tool made.
An alternative to this workflow is to use the option --keep-both
. When expected and
actual output of an example differ, it duplicates the example, marking the two copies
# optional - EXPECTED
and # optional - GOT
. (Thus, when re-running the doctester,
neither of the two copies is run; this makes ./sage --fixdoctests
idempotent.)
When exceptions are expected by an example, it is standard practice to abbreviate
the tracebacks using ...
. The doctest fixer uses this abbreviation automatically
when formatting the actual output, as shown in the above example.
To disable it so that the details of the exception
can be inspected, use the option --full-tracebacks
. This is particularly useful
in combination with --keep-both
:
[mkoeppe@localhost sage]$ ./sage --fixdoctests --keep-both --full-tracebacks \
--overwrite src/sage/arith/weird.py
This will give the following result on the above example:
| r"""
| ...
|
| EXAMPLES::
|
| sage: 2 + 2 # optional - EXPECTED
| 5
| sage: 2 + 2 # optional - GOT
| 4
| sage: factor("91") # optional - EXPECTED
| "7" * "13"
| sage: factor("91") # optional - GOT
| Traceback (most recent call last):
| ...
| File "<doctest...>", line 1, in <module>
| factor("91")
| File ".../src/sage/arith/misc.py", line 2680, in factor
| raise TypeError("unable to factor {!r}".format(n))
| TypeError: unable to factor '91'
| ...
| """
To make sure that all doctests are updated, you may have to use the option --long
:
[mkoeppe@localhost sage]$ ./sage --fixdoctests --long \
--overwrite src/sage/arith/weird.py
If you are not comfortable with allowing this tool to edit your source files, you can use
the option --no-overwrite
, which will create a new file with the extension .fixed
instead of overwriting the source file:
[mkoeppe@localhost sage]$ ./sage --fixdoctests \
--no-overwrite src/sage/arith/weird.py
Use in virtual environments#
The doctest fixer can also run tests using the Sage doctester installed in a virtual environment:
[mkoeppe@localhost sage]$ ./sage --fixdoctests --overwrite \
--distribution sagemath-categories \
src/sage/geometry/schemes/generic/*.py
This command, using --distribution
, is equivalent to a command
that uses the more specific options --venv
and --environment
:
[mkoeppe@localhost sage]$ ./sage --fixdoctests --overwrite \
--venv pkgs/sagemath-categories/.tox/sagepython-... \
--environment sage.all__sagemath_categories
src/sage/geometry/schemes/generic/*.py
Either way, the options --keep-both
, --full-tracebacks
, and
--if-installed
are implied.
In this mode of operation, when the doctester encounters a global name
that is unknown in its virtual environment (NameError
),
the doctest fixer will look up the name in its own environment (typically
a full installation of the Sage library) and add a # needs ...
tag
to the doctest.
Likewise, when the doctester runs into a ModuleNotFoundError
,
the doctest fixer will automatically add a # needs ...
tag.


|
|
|
|
P |
R |
O |
G |
R |
A |
M |
M |
I |
N |
G |
|
C |
O |
M |
P |
E |
T |
I |
T |
I |
O |
N |
|
Golf
|
Task #5
|
Novice |
5
Points |
Task Description
Tiger the Robot plays a perfect game of
golf. When he hits the golf ball
it always goes directly towards the hole on the green, and he always hits
exactly the distance that is specified for the club. Each such action is known as a stroke, and the object of
golf is to hit the ball from the tee to the hole in the fewest number of
strokes. Tiger needs a program to
select the best combination of clubs to reach the hole in the fewest
strokes. Tiger can carry up to 14
clubs, and the total distance from the tee to any hole ranges from 100 to 600
yards. Tiger can also play up to
18 holes with the same set of clubs.
Tiger must hit the ball the exact distance to the hole in order for the
ball to drop in the hole.
Program Input
The first line of input is the
number of clubs (between 1 and 14).
For each club, a line follows specifying the distance (in yards) the
club will hit the ball (between 1 and 300). The next line of input is the number of holes (between 1 and
18). For each hole, a line follows
specifying the distance (in yards) from the tee to the hole (between 100 and
600) and the par for the hole (between 1 and 5). The notes to the right of the data will not be in the input
file. They are provided here for clarification.
10
<- 10 clubs are in Tiger’s bag
250 <- Yardage club 1 can
hit the ball
175 <- Yardage club 2 can
hit the ball
125 <- Yardage club 3 can
hit the ball
75 <- Yardage club 4
can hit the ball
50 <- Yardage club 5
can hit the ball
25 <- Yardage club 6
can hit the ball
10 <- Yardage club 7
can hit the ball
5 <- Yardage
club 8 can hit the ball
2 <- Yardage
club 9 can hit the ball
1 <- Yardage
club 10 can hit the ball
3 <- 3 holes
for this golf course
453 5 <- First hole is 403 yards, par 5
133 3 <- Second hole is 133 yards, par 3
350 4 <- Third hole is 350 yards, par 4
Program Output
Print out Tiger’s scorecard for this round of
golf. For each hole, print the
hole number, the minimum number of strokes for the hole, the number of strokes
above or below par for the hole, the total number of strokes to this point, and
the total number of strokes above or below par to this point (see below for an
example). Output the results to an
output file. You must include the
scorecard header as shown below.
Total
Total
Hole Strokes +/- Strokes +/-
==== ======= === ======= =====
1 5 0 5 0
2 4 +1 9 +1
3 3 -1 12
0


Bold List list paragraphs
Simple section with bold text.
Item 1
Item 2
Item 3
More stuff
item
another item
One Two
Three
Four Five
Six Seven
Eight
Nine
Ten
Eleven Twelve
Thirteen Fourteen


Given semester long projects to program, engineer, build, and create to a certain standard. Those project involved research and creativity.
Database management and Web Development.
Updating/rewriting an existing Active Directory Query Management application using ASP.NET Core MVC with Angular and Kendo UI.
Created a Trivia game consisting of questions about the school. It allowed multiplayer settings to where people could compete to answer the questions using buzzers that were programmed into the game.
Working on the implementation of an interactive children eBook. The project includes adding more interactive stories to the book, improve the multi-lingual dictionary feature as well as highlighting and many more.
GPA: 3.62
Results: 81%
Apart from being a full time Computer Science student, I enjoy cooking and watching tv shows such as "Station 19" and "How to get away with murder".
 I enjoy Martial Arts and weightlifting.
The project and research consist of implementing some functionalities where a reader can highlight an unfamiliar word on the screen while reading a story and get the appropriate definition back. The definition will be appropriate to the child's reading level, language and the context of the book.
The project consists of creating an augmented reality environment for use in Astronomy Lab The environment focuses not only on students/teachers interaction during class time.


Characterized by an exponential growth in data being generated, stored, and shared on a daily basis, the dawning of the information-technology revolution and globalization has led modern sports organizations to consider advanced data analysis techniques to facilitate the decision-making process with the hope of improving their desired outcomes. Rather than base these decisions solely on wisdom and expertise, the quality of which is often compromised by gut instinct and distorted memories, some sports practitioners are now making better decisions by utilizing the cost-effective and timely methods of data science. The challenge, then, and that which consititutes the purpose of this website, is to meet the growing demand for individuals with the skills to process, analyze, and communicate the information contained within the available data.
Chris Brammer, PhD
Omaha, Nebraska
“The ‘datification’ of virtually all facets of life represents an enormous opportunity to inform our understanding of human performance. And I am enthusiastic about taking full advantage of the opportunity!”


This tool matches a draft abstract with the best-matching open access journals. Find somewhere to submit your work by pasting your abstract below!
How does it work? Find out more.
Your results...
Loading...
This will take 1 to 3 minutes. Maybe a good time to refill your coffee?
This tool compares the similarity of user-submitted abstracts with abstracts from the Directory of Open Access Journals,
and provides a list of the 5 top matching journals.
It is not meant to be forensic (it won’t tell you what journal an abstract came from), but rather it is meant to be serendipitous (maybe you’ll discover a new
journal that you like!).
While other journal matching projects exist, to my knowledge none of them are fully open source and fully interdisciplinary.
All of the code for this project is openly licensed and is available on Github,
as is the code for the underlying matching algorithm, spaCy. Both use an MIT license.
The matcher's recommendations are also all open access.
This application was built by Mark Eaton with the support of a Google Cloud
Platform Credit grant. The computationally intensive data processing runs on a "serverless" Google Cloud Function.
This tool will only work with abstracts written in English.


Start Time: {{ trackerService.config?.startTime | date: "d MMM y, h:mm:ss a" }}
Last 5 games
| Team | Total Kills | Games Played | Points |
|---|---|---|---|
| {{ entry.team }} | {{ entry.totalKills }} |
|
{{ entry.points }} |
{{ award.description }}
{{ award.playerName }}
{{ award.team }}
{{ award.value }}
Total player kills scoreboard. Players who share a position will be sorted based on total damage across all played games.
| Pos. | Player | Total Kills | Team |
|---|---|---|---|
| {{ entry.pos }} | {{ entry.name }} | {{ entry.kills }} | {{ entry.team }} |


Hi, I'm Conor – I'm a software engineer.
I'm interested in the web, security, and how technology can solve global problems. I'm also interested in trivia, the environment, sports, and days in the park.
I'm a recent graduate from the University of Michigan and started work last year at Salesforce. I'm happily employed, but I'm always excited to meet people working on interesting things – feel free to shoot me an email. And while you're here, check out my projects and my resume!


Student Welfare Centre
11 April 2018 / 22:38:43
Home
About SWC
Services
Team
Contact Us
Student Experiences