Follow these holiday shipping deadlines to get packages to loved ones on time
by Kyle HicksThe holiday season is upon us, which means it’s time to start shopping for gifts and planning how to get them to your loved ones.
If you plan to ship packages through the U.S. Postal Service (USPS), it’s important to mail them out early enough to be delivered by Christmas.
The Postal Service recommends the following mailing and shipping deadlines for expected delivery by Dec. 25 to Air/Army Post Office/Fleet Post Office/Diplomatic Post Office and domestic addresses:
- Dec. 9 — APO/FPO/DPO (ZIP Code 093 only) Priority Mail and First-Class Mail
- Dec. 11 — APO/FPO/DPO (all other ZIP Codes) Priority Mail and First-Class Mail
- Dec. 14 — USPS Retail Ground
- Dec. 18 — APO/FPO/DPO (except ZIP Code 093) USPS Priority Mail Express
- Dec. 20 — First-Class Mail (including greeting cards)
- Dec. 20 — First-Class packages (up to 15.99 ounces)
- Dec. 21 — Priority Mail
- Dec. 23 — Priority Mail Express
Alaska
- Dec. 18 — Alaska to mainland First-Class Mail
- Dec. 19 — Alaska to mainland Priority Mail
- Dec. 21 — Alaska to mainland Priority Mail Express
Hawaii
- Dec. 19 — Hawaii to mainland Priority Mail and First-Class Mail
- Dec. 21 — Hawaii to mainland Priority Mail Express
The Postal Service’s busiest time of the season peaks two weeks before Christmas, when much last-minute shopping starts. Customer traffic is expected to increase beginning Dec. 9, while the week of Dec. 16 is expected to be the busiest time for mailing, shipping and delivery. Additionally, the Postal Service predicts that nearly 2.5 billion pieces of First-Class Mail, including greeting cards, will be processed and delivered the week of Dec. 16.
The Postal Service says it will expand Sunday delivery beginning Nov. 24 to locations with high package volumes. USPS already delivers packages on Sundays in most major cities and anticipates delivering more than 8 million packages on Sundays in December.
USPS offers mailing and shipping tips for the holiday season:
- Use free Priority Mail Flat Rate boxes. They are available at local Post Offices or online at usps.com/freeboxes .
- Make it easy with Click-N-Ship. You can create shipping labels and pay for postage online at usps.com/ship.
- Schedule a free Package Pickup when the carrier delivers your mail. It’s free regardless of the number of packages. Or, pickups can be scheduled at usps.com/pickup .
- New this year, mail and packages weighing more than 10 ounces and/or are more than a half-inch think using stamps as postage cannot be dropped into a collection box or left for a carrier to pick up. Instead, take them to a window clerk at a Post Office. Click-N-Ship customers are unaffected by this change.


HTML tags can be on the same line, or...
... on different lines! Just make sure the opening and closing tags exist.
So, now you gonna teach me This should be a paragraph. Surround me!
Oh no
Map


After processing the data, the FOA unit sends the country level results to the FAO Statistics Division for dissemination.
Figure 4: Forestry Production and Trade dissemination page (FAOSTAT)


"gr-shiny" is a Shiny app for some of the existing genomic-range GSA tools. Open R and run gr-shiny in two simple steps: Install required packages Run app
GSA Central, 2022 Last updated: May 12th, 2022


Implementation Status
BiwaScheme aims to conform to the latest specification of the Scheme language,R6RS.
Most of the important features are already supported. The biggest features not implemented are errors and hygenic macros (for now, BiwaScheme has 'define-macro' instead).
R6RS Base library
| section | title | status |
|---|---|---|
| 11.4 | Expressions | almost ok |
| 11.5 | Equivalence predicates | ok |
| 11.6 | Procedure predicate | ok |
| <IP_ADDRESS> | Numerical operations | almost ok |
| 11.8 | Booleans | ok |
| 11.9 | Paris and lists | ok |
| 11.10 | Symbols | ok |
| 11.11 | Characters | ok |
| 11.12 | Strings | ok |
| 11.13 | Vectors | ok |
| 11.14 | Errors and violations | not yet |
| 11.15 | Control features | ok |
| 11.16 | Iteration | ok |
| 11.17 | Quasiquotation | almost ok (except vector quasiquotation) |
| 11.18 | Binding constructs for syntactic keywords | not yet |
| 11.19 | Macro transformers | not yet |
| 11.20 | Tail calls and tail contexts | ok? |
R6RS Standard Libraries
| 1 | Unicode | not yet |
| 2 | Bytevectors | (no plan) |
| 3 | List utilities | ok |
| 4 | Sorting | not yet |
| 5 | Control structures | partially ok (when, unless) |
| 6 | Records | not yet |
| 7 | Exceptions and conditions | not yet |
| 8 | I/O | partially ok (output to 'stdout') |
| 9 | File system | (no plan) |
| 10 | Command-line access and exit values | (no plan) |
| 11 | Arithmetic | not yet |
| 12 | syntax-case | not yet |
| 13 | Hashtables | almost ok |
| 14 | Enumerations | not yet |
| 15 | Composite library | not yet |
| 16 | eval | almost ok (eval) |
| 17 | Mutable pairs | (no plan) |
| 18 | Mutable strings | (no plan) # because JavaScript does not provide mutable strings |
| 19 | R5RS compatibility | (no plan) |
'(no plan)' means that I have no plan to support it, but does not mean will never include it; patches are welcome.
SRFIs
See http://srfi.schemers.org/ for SRFI (Scheme Requests for Implementation).
| 1 | list utilities | partially (iota) |
| 6 | string port | ok |
| 13 | string utilities | not yet |
| 19 | time | partially |
| 27 | random | partially (random-integer) |
| 30 | multi-line comment | ok |
| 38 | write/ss | partially (write/ss) |
| 43 | vector | partially (vector-append) |
| 62 | s-expr comment | ok |


Before Change
if epoch_batches is None:
batcher.reset()
return np.mean(train_loss), global_step
def train_epoch_tfr(self, sess, sum_writer=None, epoch_batches=None):
Execute one training epoch, using TFRecords data.
After Change
// initialize training loss
train_loss = []
batch_sizes = []
global_step = 0
// setup feed dict
fd = self.set_mode("train")
// get first batch
Xb, Yb, NAb, Nb = batcher.next()
batch_num = 0
while Xb is not None and (epoch_batches is None or batch_num < epoch_batches):
// update feed dict
fd[self.inputs_ph] = Xb
fd[self.targets_ph] = Yb
if no_steps:
run_returns = sess.run([self.merged_summary, self.loss_train] + \
self.update_ops, feed_dict=fd)
summary, loss_batch = run_returns[:2]
else:
run_ops = [self.merged_summary, self.loss_train, self.global_step, self.step_op]
run_ops += self.update_ops
summary, loss_batch, global_step = sess.run(run_ops, feed_dict=fd)[:3]
// add summary
if sum_writer is not None:
sum_writer.add_summary(summary, global_step)
// accumulate loss
train_loss.append(loss_batch)
batch_sizes.append(Nb)
// next batch
Xb, Yb, NAb, Nb = batcher.next()
batch_num += 1
// reset training batcher if epoch considered all of the data
if epoch_batches is None:
batcher.reset()
avg_loss = np.average(train_loss, weights=batch_sizes)
return avg_loss, global_step
def train_epoch_tfr(self, sess, sum_writer=None, epoch_batches=None):
Execute one training epoch, using TFRecords data.


{{ message }}
Reverse Message
Add 1
The button above has been clicked for {{counter}} times.
Greet
Say hi
Say what
Submit


- CISAP_LOCATION_ACCURACY_MINIMUM - Static variable in class saarland.cispa.bletrackerlib.BleTrackerPreferences
-
- CISAP_LOCATION_FRESHNESS_MINIMUM - Static variable in class saarland.cispa.bletrackerlib.BleTrackerPreferences
-
- cispaConnection - Variable in class saarland.cispa.bletrackerlib.BleTracker
-
- cispaConnection - Variable in class saarland.cispa.bletrackerlib.service.RangeNotifierImpl
-
- clearRemoteReceivers() - Method in class saarland.cispa.bletrackerlib.remote.RemoteConnection
-
Clears the callback list.
- context - Variable in class saarland.cispa.bletrackerlib.parser.SimpleBeaconParser
-
- create(Context, int, Class) - Static method in class saarland.cispa.bletrackerlib.helper.ForegroundNotification
-
Creates a permanent notification which is needed for forground scanning
- createBackgroundService() - Method in class saarland.cispa.bletrackerlib.BleTracker
-
Creates a background service which operates in the background and gets called from time to time by the system
This causes low battery drain but also the refresh rate is low
Also this will NOT!
- createBackgroundService(ArrayList<BeaconNotifier>, RemoteConnection) - Method in class saarland.cispa.bletrackerlib.service.BleTrackerService
-
Creates a service which operates in background
Do not change the order of the calls in this constructor without knowing what you are doing!
- createBasicSimulatedBeacons() - Method in class saarland.cispa.bletrackerlib.service.TimedBeaconSimulator
-
Creates simulated beacons all at once.
- createForegroundService(Notification) - Method in class saarland.cispa.bletrackerlib.BleTracker
-
Creates a service which also operates in background but will never go asleep thus your app stays in foreground
This causes huge battery drain but also gives a very good refresh rate
- createForegroundService(ArrayList<BeaconNotifier>, Notification, RemoteConnection) - Method in class saarland.cispa.bletrackerlib.service.BleTrackerService
-
Creates a service which also operates in background but will never go asleep
Do not change the order of the calls in this constructor without knowing what you are doing!
- createTimedSimulatedBeacons() - Method in class saarland.cispa.bletrackerlib.service.TimedBeaconSimulator
-
Simulates a new beacon every 10 seconds until it runs out of new ones to add.
- customConnections - Variable in class saarland.cispa.bletrackerlib.service.RangeNotifierImpl
-


Contain
Your Excitement
Timirah James ★ Connect.TECH ATL ★ 2018
Thanks [intro person]
Who am I?
@TimirahJ
Developer Advocate @ Cloudinary
Founder @ TechniGal LA (Meetup Group)
Singer/Songwriter "Coderitis" - GERNiE B.
*Cloudinary*
I currently work as a developer advocate at Cloudinary. Cloudinary is an image and video back-end for web and mobile developers. If you work with images – especially responsive images — Cloudinary can help you do that work better. We actually don't have a booth this year, but feel free to bug me or my colleague Eric who actually gave an awesome talk about lazy and progressive images earlier today -- if you wanna learn more about us.
Prior to working at Cloudinary, I actually spent a large part of my career working on mobile development and most recently serverless solutions.
*TechniGal LA*
*Coderitis*
*Background*
So that leads me to the last thing I wanna share about myself. I actually got my start in tech right here in Atlanta. I went to a performing arts high school not too far from here, and during my junior year I stumbled upon this flyer about a tech program that was seeking high school students to be interns at tech companies throughout the Metro Atlanta Area. I had zero experience as a programmer, but my curiousity got the best of me. So I hopped online and crammed as much info as I could to build a crappy website. Just enough to showcase my eagerness and potential. And next thing you know I began training as a web development intern for at a local tech company for two consecutive summers.
So I just thought that was a pretty cool thing to share.
So today, I want to talk to you about
Element queries!
Element queries!
[click]
Or container queries, or whatever.
I suppose a brief note on terminology is in order
“Element?” “Container?”
Same-same.
We’ll get into the distinction between “element” and “container” queries later, but for the first part of this talk, I’ll use the terms more or less interchangably.
= media queries for elements
Both terms to refer to the same idea. In a nutshell: we should be able to adapt element’s styles based on their own state. Not just the state of the entire viewport.
Media queries are a whole-viewport-solution...
...designed to solve whole-document problems.
It’s worth taking a moment to think about about where Media Queries came from.
How many of have ever written a print-specific stylesheet?
<link rel="stylesheet" type="text/css"
media="print" href="serif.css">
<link rel="stylesheet" type="text/css"
media="screen" href="sans-serif.css">
@media print {
* { font-family: serif }
}
@media screen {
* { font-family: sans-serif }
}
@media screen and (min-width: 400px) {
...
}
Well the original media queries spec, published about 17 years ago, opens with the following example. In ye olden dayes, it was actually pretty common for webmasters to provide a cascading style sheet for screens and a separate cascading style sheet for print, containing styles tailored for laser-printed pieces of paper.
The media queries spec says, hey, this is a decently common use case -- how about we let you wrap these two sets of styles up into the same stylesheet, like this:
[click]
“Media” queries were designed to let you wrap your media-specific styles in a little @media block -- and no separate stylesheet is required.
As luck would have it, the spec authors thought, well, as long as we’re letting you query media *types*, we might as well also let you query specific media *features*, like width.
[click]
And just like that, this form of media queries that we all know and love were born.
Element Queries, explained by Tommy Hodgins
“If we think in terms of building a large physical structure with weak material. A great amount of external support is required to hold it together, and they things have to be overbuilt to stay sturdy. When you’re building a website using HTML, CSS, and Javascript, this external support would probably look like frameworks, plugins, preprocessors, editing tools, package managers, the works!” Instead of adding yet another plugin to the top of the stack, what if, by extending one of the core languages, CSS, we could strengthen the material that websites are built from, developing better, stronger websites that require less external support and tools to build? Thus, element queries!”
Responsive pages
When we we’re designing web *pages*, and we want to adapt those pages in response to the state of the *whole viewport*, they’re a great solution.
But increasingly, we’re not really designing monolithic pages.
[click]
We’re designing modular *components*. And what we want, is the ability to set breakpoints directly on those components.
Whether you’re working with Web Components, React components, style-guides and pattern libraries, etc, media queries are a kludge and are for the most part can be considered a hack.
.block {
background-color: lightblue;
}
@media (min-width: 797px) {
.block {
background-color: deeppink;
}
}
.block:min-width(100px) {
background-color: deeppink;
}
So now let's go thru an example! Let’s say I've got a line of five little light-blue flexible components, like this.
And let’s say that when these boxes get to be 100px wide, I want to change them in some way – lets say I want to make them pink.
[drag box]
Just like that..
So, I'll write a media query. I'll figure out how wide the entire viewport is, just as each element hits 100px-wide. And use that whole viewport width as my min-width, like this
[click]
Now what I’ve done here, that’s hacky and bad, is embed a bunch of stuff regarding the external state into what should just be a statement about width of each box. Remember, all I should be concerned about is the width of the boxes. If they’re at least 100px wide, make them pink. But now I'm in a situation where, if many things *around* the boxes change -- let's say I tweak my margins [click], or change the number of boxes [click] -- The media query no longer does what I want, and I’ll have to change it. [click] That's bad and not what we want at all!
What we really want to be able to say, here, is say exactly what I mean. When these specific *elements* are at least 100px wide, turn them pink. I want to be able to say something like this [click].
That's an element query.
Responsive Containers by Andy Hume
Here’s the first mention I that could find of the general concept – a clear and concise six-year-old blog post from Andy Hume, complete with a working, JavaScript-based implementation of the idea. Andy called them “Selector Queries”.
Turns out, they were a good idea...
...and it wasn’t too long before some of the smartest minds in the industry were calling element-level queries “the number one missing tool for responsive design.”
By 2014, serious efforts were underway to turn what had just been an exciting idea into an empowering reality.
But. There were problems. More on those later.
For now, I just want to take you on a journey of increasingly sad and desparate tweets.
It starts innocently enough, with earnest pleas and sound arguments.
But by 2015, impatience started to set in.
Front end developers began do wonder... is anyone listening?
How many times do we have to say it?
Doesn’t anybody understand what a big deal element queries would be?
Evidently, they don't. Diffrent developers have responded to this differently. Sadness is a common reaction.
Others have resorted to dry humor.
Bitterness (you know, sometimes the saddest tweets are the truest tweets...)
And desperate cries for help
Some, sadly, have been driven to madness.
My favorite response might be Nicole Sullivan's. Nicole thought, well, if I can't have element queries, at least I can have $20!
But for those who, in 2017, still nurture hope, the message is loud and clear
What’s the hold up?
So what's the hold up? Element queries are clearly in demand. Why haven’t they been implemented yet?
To understand that, we need to take a close look at how browsers actually turn CSS and HTML into rendered pixels on screens
Please excuse a wildly simplified explanation of
the rendering pipeline
We'll call the series of processes that does this, the “rendering pipleine.”
A big ol' diagram
Start with text files - our HTML + CSS
[click]
Which we then load over the network, and parse into data structures.
[click]
Our HTML gets parsed into a DOM tree
[click]
And our CSS gets parsed into the CSS Object Model - which is represented here by this shrub or bush.
[click]
Alright so now that weve got our object models, we run all of the selectors and figure out which rules apply to which elements
[click]
and end up with a Render Tree. The Render Tree contains, basically, the “computed” styles — what we see when we inspect an element with dev tools. But there are still a few key values missing: anything having to do with the element’s size or position on the page. Figuring *that* stuff out is left to the next step
[click]
Layout! Which, is a very complex process that, when complete, gets us a
[click]
Box Tree. And now that we know the size and position of every element,
[click]
we can actually paint pixels,
[click]
and display a webpage.
So! That's how browsers render a webpage. Where do element queries fit into this picture?
[click]
Element queries introduce giant backwards arrow, from the box tree, all the way back to running selectors.
In order to know which selectors apply to an element, we have to know it's layout.
This inserts a giant loop into a previously linear pipeline.
And it's bad for three reasons.
🔁
Problem #1:
Circular dependencies
First! Circular dependencies, aka, infinite loops.
Now that the layout can affect our styles, which can effect the layout, which can affect the styles, which can affect the layout – well, you can see the problem. Now that we have a loop, what's to stop us from going round-and-round, forever?
[click]
.block:min-width(10em) {
width: 5em;
}
An example is in order. What do you think this query will do?
We're saying, if the block is wider than 10 em, make it 5em wide.
But if the browser makes it 5em wide, the query will no longer apply, and it will go back to it's original width.
Which then makes the query true again – and we're off.
I'm about to show you what that looks like..
[drag element out]
oh. Oh dear. CSS should never do that.
[drag back]
And you might be thinking, well, ok, that's clearly bad, but look at the ridiculous code you wrote? Surely *I* would never write anything as cringey as that.
I know you might be thinking this, because I thought it too. But, for most people who have tooled around with this stuff for any amount of time, let me tell you -- they've more than likely written themselves into infinite loops *several times*.
When you're querying an element's width, any rule that you apply that changes the width of the element, risks putting you into a loop. And that can happen in some unexpected places, like this... [click]
.container {
display: flex;
}
.block:min-width(3em) {
border: 0.25em solid deeppink;
}
Like this.
Here, I've got three little divs in a flexbox-row, and when they reach a certain size, I want to put a border around them.
Well, the border will get added outside of their content box. The space that each of them occupies on the layout will grow. So to fit into their flex container, with their borders, they all have to shrink. You can see where this is going.
Take a look..
[drag]
Well. That's unfortunate. Next slide.
Super
califragilistic
expiali
docious
.container {
display: flex;
}
.block:min-width(3.25em) {
letter-spacing: 0.1em;
}
Element queries can get you into some other weird situations.
Like here, I've got four divs in a flexbox, and when they get to a certain width, I'm adding some letter-spacing.
Seems simple enough.
[start dragging]
And yah, ok, that worked. But what happens when I shrink them again?
[shink]
Califragilistic is stuck. It can't go back to it's initial state, because its new rules, combined with its content and the way flexbox works, mean that it, well, cant.
I don't know. That makes sense, after you think it through. But it's weird.
Element Queries
And so this is where we go from talking about *element* queries
[click]
to talking about *container* queries.
The goal here is to break the loop. If letting elements query *themselves* is so problematic, maybe we can restrict them to querying their *container*?
.wrapper {
border: 0.0625em solid deeppink;
}
.block:container(width > 10em) {
width: 5em;
}
Here's our first element-query-infinite-loop example, written with container queries.
I've wrapped my blue box up in a pink container.
[drag element out and in a time or two]
So that didn't quite work out.. And this has a lot to do with heredity.
By querying the parent, but setting styles on the child, We've avoided an infinite loop. So, we should be good right?
Not quite.
See there are all sorts of things that we can do in CSS to get a parent's size to be affected by its children.
For instance: what happens if we float the container?
[click]
The floated container is now "shrinkwrapping" to fit its contents.
Which, right now, are set to be 100% of their parent -- so everything reduces to zero. But let's give our element an initial size.
[click]
Well, that's a real pile of poo.
Next slide.
Two solutions...
Container queries, in and of themselves, don't totally get us out of this mess. But I'm happy to report that not one but *two* solutions to this problem, actually do.
(closest) Container (whose width is not influenced by its children) Queries
The first is completely automatic, and somewhat subtle. Basically, if an element’s size *can* possibly be affected by its children, skip over it, and make the query apply to the next anscestor up the chain.
Conceived of + implemented by Martin Auswo¨ ger
This idea was, to my knowledge, first conceived of, and then implemented by, Martin Auswöger, in his container query prolyfill, which is called `cq-prolyfill`. It works!
contain: strict;
Spec’d in CSS Containment Module Level 1 and implemented in Blink
There's another working idea out there, too, which asks authors to be more explicit – CSS Containment.
Basically, if you slap a contain:strict; on an element, you’re telling the browser in very plain terms that should it *never* let that individual elements' children determine anything about its size.
Both Martin's solution, and contain:strict, separate what we're querying, from what we're adapting. By doing so, they prevent us from ever creating circular dependencies.
So -- first problem: solved! On to the next one.
🏚
Problem #2:
Breaks layout engine architecture
Remember our pipeline? For twenty years, browsers have been following that path from left, to right, in a single pass.
Even if we can solve the problem of *infinite* loops -- finite numbers of trips around the loop are still problematic. Especially when browsers assume and have always assumed that we can figure out which styles apply to what elements BEFORE we know how large those elements are.
The browser-engine-rendering-architecture problem was nicely summarized by Elika Etemad, aka fantasai, of the CSS Working Group, in response to a question asked by none other than Sarah, about what it would take for Container queries to become a thing.
[read slide]
Doesn't sound promising.
On Thu, 21 Mar 2013 at 3:08 PM, Elliott Sprehn wrote :
> This doesn't seem very easy to implement because it breaks the sequential
> processing model :
>
> 1. resolve style on elements such that you have a flattened set of
> properties.
> 2. layout the elements if things are different then the last time we did
> step 1.
> This would be a big undertaking in Webkit so I don't think it falls
> anywhere in the near future.
On Thu, Mar 21, 2013 at 6:34 PM, Elliott Sprehn wrote :
> I think there's a high implementation cost for this kind of thing
> It certainly could be done given enough time and someone very
> motivated...
And here’s Elliott Sprehn, from the WebKit team, saying the same thing.
breaks the model... big undertaking... high implementation cost...
Container queries would be an unusually large amount of work, for implementors.
But, as we saw earlier, there has also been an extraordinary amount of demand for them, from authors.
So what we've got here, is an unstoppable force — authors working with components in responsive designs — meeting an immovable object, which is 20 years of tightly-optimized code in browsers, whose fundamental architectural assumptions, container queries would break.
What happens when those things collide?
From the HTML Design Principles
That answer lies within the HTML design principles. It's called the "priority of constituencies", and it states that...
“in case of conflict, consider users over authors over implementors over specifiers over theoretical purity.”
This is a beautiful statement, which, at multiple levels, implores the powerful few to understand and serve the relative many, who must live with the products and consequences of their work.
Also, it means, we win, right!?
[click]
Authors over implementors! That means if we want container queries, but implementors think they’d be really hard or whatever – too bad! Quit your bitchin’ and start re-architectin’!
Not so fast. In this hierarchy. There is one constituency whose concerns can, and should, matter more than ours.
[click]
Users. Which brings us to the last, biggest, and best reason that Container Queries aren’t a thing yet.
🐌
Problem #3:
Fundamentally slow
They’re fundamentally slow.
🐇
...and it needs to be FAST
And we're introducing them into a process that needs to happen really, really, fast. Browsers like to be able to paint at the refresh rate of the display. Usually, now-a-days, that means 60 frames per second.
16 milliseconds
That means we have to complete all of our layout and paint work once every 16 milliseconds. Especially on low-powered mobile devices, every one of those milliseconds is precious.
5ms best / 35ms worst
Let me give you a high-level sense of what that number means... My computer is not a low-powered mobile device, it’s a 15" macbook pro.
And when I look at a fairly simple, well-architected, responsive page that uses media queries, like, say SmashingConf.com, and measure the performance of the site as I resize the window, I can drill down into the dev tools and see that, most of the frames are happening right on schedule at 60FPS. Not only that, most of the time between frames is, in fact, idle on the main thread.
The browser is spending about 5-ish milliseconds re-figuring layout and re-painting in response to the changing window size, and it has about 10 or so milliseconds to spare.
If you look closely at this screenshot, you can see that we are dropping a few frames --- mostly because of the work that we're doing to re-size the fluid bitmap images at the bottom of the page. And we do actually drop a couple of frames every once and a while due to layout -- here, it looks like I hit a major breakpoint **right** at the end of a frame, and the browser had to spend a chunk of time calculating and painting the new, significantly different layout... not great, but still, visually, the experience of resizing this page is more or less seamless.
So that gives you a little bit of a sense, maybe, of the baseline we're working with - of what that 16ms budget actually looks like, in practice.
So let's take a look back at our pipeline, now that we've introduced container queries..

Even if we've figured out how to prevent infinite loops, and even if we re-architect browsers to be able to *do* loops – container queries, fundamentally, require taking one or more trips around the loop. Basing styles on styles and layout on layout is literally the whole point.
Every trip around the loop takes time. And if we start using container queries as liberally as we use media queries, today – container-querying all the things... and especially if we start *nesting* container queried components within container-queried components – we might be taking dozens or even hundreds of trips around the loop, each frame.
That's bad for users.
I'm going to show you an example, built with Tommy Hodgin’s prolyfill, EQCSS. Tommy Hodgins has done more work than anyone, anywhere, advocating for Container Queries. He’s built this pollyfill, stuffed it with features, and he’s amassing a frankly staggering library of demos.
I asked him for his worst-performing demo.
40ms best / 150ms worst
He kindly sent me this pricing comparison chart. Which, when I resized it, well – it's kind of complicated.
First of all, the *visual* performance is more or less ok, but it also feels, I don't know, off. A bit weird.
Drilling into the dev tools, we can see why. EQCSS throttles itself, and waits 200ms between executions.
But every time EQCSS’ resize handler does run, it takes a minumum of 40ms, which means we’re missing a three or four frames.  If you drill down and look what’s taking all of that time, Chrome Dev Tools shows you all of these little purple layout boxes with bright red corners, signifying forced reflows that the plugin needed to do as part of its container-querying-work. Each one represents a small trip around this plugin’s particular implementation of the element-query loop for some subtree of the page. Add them up, and you get 6fps performance, instead of 60.
Paths forward
So -- where does that leave us? How do we move forward?
I'm happy to report that some very smart people have some very good ideas and are actively working on pieces of this puzzle.
contain: strict;
to the rescue?
The first puzzle piece, we've already mentioned, actually: CSS Containment. I said before that Containment might be the thing that prevents us from creating infinite container query loops – well, it might help offset some of the performance impact of container queries, too. When we prevent children from being able to influence the size, layout, or appearance of their parents – turns out – browsers can usefuly limit and optimize a bunch of layout work. So perhaps, a solution that brought a lot of both container queries **but also** CSS containment to the web, wouldn't be so bad for performance after all.
I haven’t done a lot of testing here myself, but Paul Lewis published this example when the `contain` property landed in Chrome, showing a re-layout time dropping from 50-something ms all the way down to 0.05ms, all because of this one weird CSS property.
I dunno. Seems promising?
Asynchronicity
Knock. there? Async container queries Who’s knock!
The second, and more important idea is: make sure that, even if our container querying is slow, we minimize the damage that we’re doing to users’ experiences by doing the work ~asynchronously~.
Browsers respond to Media Queries synchronously. Which is to say, when a media query toggles between true and false, the browser’s entire world stops for as long as it needs to so that it can respond to the change.
If we can't make container queries as performant as media queries, perhaps we can make them a little less world-stopping. We can let the browser re-schedule container query work, or maybe even push it to the next frame, so that we can continue to keep the rest of the user’s experience from feeling "stalled" or "stuck".
I’m happy to report that there’s a working implementation of this idea too, behind a flag in Chrome:
It's called ResizeObserver.
The more I learn about ResizeObserver, the more I love it. It’s pretty much a purpose-built Container Query toolkit.
First and foremost, ResizeObserver lets you attach resize event listeners directly to elements. The current batch of prolyfills have to listen to a whole bunch of possibly-related events –– like window resizes and DOM changes -- and then check to see if any element resizing actually happened, after the fact. ResizeObserver’s primary purpose is to let us observe elements directly.
ResizeObserver also provides access to a stripped-down set of very-cheap-to-query element geometry. Current prolyfills all have to make extensive use of element.getComputedStyle(), which forces a reflow to insure that the queried styles are up-to-date. ResizeObserver gives you access to fresh element geometry far more cheaply.
Also -- asynchronus execution. The callbacks that you register with ResizeObserver are treated as what browsers call "microtasks." Which means that the browser doesn’t have to drop everything and run them to completion as soon as a resize happens. Instead, they're batched up and run at a precise, later time: just after the next layout and just before the next paint. This ensures that you're not doing any work too early -- you're not going to be surprised by any layout changes happening under your nose. Better yet, batched-up microtasks don’t interrupt any other super-important intra-frame work - like, say, responding to user input - and if they do take too long to run, browsers are entirely free to push them to the next frame, so that we don't end up killing the frame rate.
Oh! And! ResizeObserver *also* features a smart way to deal with infinite loops. Because we're in Javascript land, it *can't* keep you from creating infinite layout→response→layout→response→layout→response loops. But it does use a thoughtful strategy – based on nesting-levels - to make sure that it breaks out of those loops in sensible ways, so that the browser can paint, deal with other work that it's doing, and wait to take take one more trip around the infinite loop until the **next** frame.
You've already seen examples of that. This very slide deck, is running a simple, ResizeObserver-based container-query implementation that I slapped together for the purposes of this talk. All of the looping examples that I've shown you flicker between states exactly once per frame, without freezing, stuttering, throwing an exception, or preventing me from interacting with the page, because they were built with ResizeObserver.
In short, ResizeObserver -- perhaps combined with explicit CSS containment -- might give us everything that we need to implement smart, as-performant-as-possible container queries -- in JavaScript.
JavaScript!?
What about CSS?
Now, wait, I hear you saying... Javascript!? Don't we want them in CSS?
Which brings me to the last big idea about how to make Container Queries a thing. Excitingly, it's where we come in.
🎩 🐇
How many of you have heard of Houdini? Some may call it the Extensible Web Manifesto?
Ok, well Houdini is a major effort to give front end developers as much access as possible to the lower-level primitives of CSS. Houdini wants to *explain the magic* of CSS, in Javascript.
The idea here is that, basically, top-down development of web platform features -- where browser vendors and spec writers make the big platform-level decisions, and humble front end developers resign themselves to living with the consequences -- is bad for everyone. Wouldn't it be better if everyday developers could implement experimental new features *themselves*? This would mean that new features were forged, not in long, hypothetical arguments on mailing lists -- but out in the real world, via real useage, on real web pages. And then, eventually, if there’s consensus around good implementations of good ideas – they’ll get pulled into the platform and supported natively.
The best example of this sort of model is, I think, JQuery. Which was iterated on for years – it became the dominant thing that everybody used everywhere all of the time – and then, eventually, its best ideas were adopted by the platform, natively.
Houdini wants to pave the way for things like JQuery to happen in CSS.
It's a grand idea and a good one. And, brought to fruition, it would mean that we, as a community, could take tools like ResizeObserver and `contain: strict`, use them to build container queries in Javascript, and then wrap the implementation up in a nice, tidy, custom CSS syntax which would be used on real web pages and iterated on it in response to observed problems and optimized for real use cases - before being baked into the web platform.
For a problem as big, and tricky, and in need of careful scoping, as container queries, you can see the appeal of this.
Well, I have some good news and some bad news.
Bad news first.
No.
Here's a handy website with, the URL ishoudinireadyyet.com
As you can see, the answer is more or less, no.
Heck, I didn't mention this earlier, but even ResizeObserver and contain:strict are currently only implemented in Blink. So while we can start to build experimental things in Chrome, you can't really deploy them to the public web yet – and you might not be able to for *years.*
That's some pretty bad news.
The Prolyfills are Alright
But the good news is that a lack of widely-supported low-level tooling hasn't stopped a gang of brave and fearless developers from MacGyvering together container-queries prolyfills, anyways. And the resulting libraries are, I’m here to tell you, surprisingly good!
I’ve already mentioned a couple of my favorites.
First, there’s Martin Auswöger’s cq-prolyfill, which implements the smart, infinite-loop-free container queries that we’ve already discussed. It’s biggest selling point, to me, though, is performance — it’s particularly smart about minimizing the number of loops that it needs to take. So despite not yet supporting ResizeObservers, in my limited testing – it is totally, usably, speedy.
Second, there’s Tommy Hodgin’s EQCSS, which, more than any other library, shows you what's *possible* with this stuff. EQCSS doesn't limit you to querying widths and heights. You can query all sorts of things, like, say, the number of lines of text within an element, or the number of children that an element has.
I should mention too, that Tommy just released a new set of libraries that he's calling CSSPlus, that allow you to do even more -- including incorporating arbitrary javascript tests into your CSS selectors. This is super-interesting and super-powerful -- it's more or less a generalized evolution of EQCSS that lets you query, not just elements, but, well, anything.
Then there’s ELQ, which is the product of Lucas Weiner’s master's thesis in computer science. It features a presumably very clever infinite loop resolver that I don't understand.
eq.js by Sam Richard features yet another infinite loop resolver - they call it "greedy" - basically it looks at all of the states in the loop and picks the... biggest? Kinda crazy, but I guess it works! My favorite thing about it is how it uses requestAnimatinoFrame to get async behavior, similar to ResizeObserver’s.
Marc J Schmidt owns one of the longest-running and most popular implementations, which he and a small team of people are still developing. It's called CSS Element Queries and my favorite thing about it, is that, in the absence of proper Houdini access points to CSS, it plays a very neat trick with the CSS attribute selector...
Victor Hubert has a brand new library called Container Query that’s the first to be built on ResizeObserver. It ships with a ResizeObserver polyfill so that you can actually use it, today...
I should also mention that the code that Shopify deployed, that I mentioned earlier, is actually open source too, and lives in a library called ContainerQueries...
And if you search GitHub for “container queries” or “element queries” you could while away a few afternoons checking out many other libraries.
Each of these prolyfills solves the circularity and performance problems inherent in Container queries in a different way. I’ve found them all to be surprisingly usable, and I think we should all be using, or at least experimenting with them.
Fight jank!
Load container query libraries in the <head>
One piece of advice, if you do: you may run into some jarring flashes of unstyled content, with these libraries. If you load them like you should be loading the rest of your javascript -- after all of your HTML and CSS -- be prepared for them to be somewhat invasive.
Thankfully, this problem has a simple solution: load your container query library in the `head`, without async or defer. Doing so will set your first paint back by a bit, but the payoff is worth it: no jarring flashes there.
Why wait? Iterate!
In any case, I’ll say it again: if you’re convinced that Container Queries are a good thing, and if you want them to become a core part of the web platform, the best thing that you can do, as a front end web developer, is to start using these libraries, today.
Maybe on smaller or personal projects at first. I think you might be suprised, as I was, by how fast and useable they are. And as ResizeObserver and Houdini support rolls out, they’re going to become much, much better.
They're going to be good and performant as any native implementation could ever be.
Help them get there, if you can. Try them out. If you run into problems, file issues.
Tweet about your experiences. Write blog posts.
Help container queries help you!
For extra credit...
If you really want to make a difference, document your useage in a place where the web platform community can see it. The Responsive Issues Community Group maintains a 'use cases and requirements' document for Container queries - if you end up using Container Queries on anything public – we wanna know about - post a link to this issue, #41 in the repo.
Carpe query.
Ok, last slide.
I don't know whether any of the libraries that I've mentioned today will *ever* become as popular as JQuery. I don't want to speculate on when container-queries will become an official part of CSS. And while I love the lofty ideals of Houdini and bottom-up web platform development, the last thing I want to do is hold container queries hostage until Houdini is ready. The web needed container queries years ago. I'll take them however they come.
So I guess my big takeaway for you all is: they're already here!
If you like the idea of container queries, don’t wait for native support to decsend from the heavens. Prolyfills give YOU a better way to build websites, today! And they embody a better way for ALL of us to build the a web PLATFORM for the future – together.
So use them! Do it for the platform, and do it for yourself.


countries laboratory Western health microbiology public Balkan national ECDC European {border-style px;} #ffffff;} systems communicable Public capacities laboratories testing need Health capacity virus) Available Disease at: collab: disease effective online support antimicrobial including molecular Control Countries Microbiology National Prevention diagnostic reference spp.) surveillance technical Centre Salmonella clinical enlargement improve px; reported services {font-family Commission candidate control country detection font-size investment key prevention quality Laboratory countries' countries, cross-border double; external financial implementation level. new pathogen primary resistance strengthen typing Bosnia Health, Institute Observers Republic addition, and/or areas assessment border-color border-width common countries. data diseases efforts exchange gaps information level methods needed patient potential pre-accession region security solid; supporting systems. {font-style {font-weight Antimicrobial Balkans Communicable EU's FEVER International Surveillance Table Yugoslav acquis address algorithms article based bold capabilities care collaboration control, cooperation coordinated courier; credible develop e.g., em; half handling identified insufficient lack monitoring network perform perspective policy pt;} regional response sample samples strategy supported susceptibility threats transformation transportation


Everyone will get a papermoney account login. Papermoney is a "thinkorswim" account, which is a trading software. We'll use this software and our thinkorswim manuals (85 pages to help everyone- youll all get a copy of this manual) to learn trading throughout the year. It'll also be used to do our awesome contest (phstfc.com/contest), the prizes of which are listed below!
The Prizes:
1st Place- $100 (or likely more) and your name on a plaque.
2nd Place- $50 (again, see later for more info on likely greater prizes)
3rd Place- $25
Bonus- If you beat my TradeMonster account (which I haven't actively traded for a pretty long time but still turned from the default 100k into around 230K) you will receive a $100 bonus (only one person will, the highest account balance above my current one at the end of the contest)! Also, we may be giving out some tastytrade T-Shirts and stuff. More on that later...
These are personally paid by Luke. If any parent or someone else wants to raise the prizes, just talk to me and we'll make it happen. It would also be awesome if someone would sponsor the club or if a financial advisor, etc. allowed for the winner(s) to receive a funded brokerage account. I'll probably be talking to a few financial industry people I know, but it would be awesome if someone would decide to do that, again- just let me know. Thanks!
I'll post each persons returns on the website (see contest page) so you guys can know where you stand and compete with everyone. Derek, don't get too obsessed.
This contest will be a big part of the club. We'll use it as a means to teach basic trading, learn about finance, charting, statistics/probabilities, etc. Also, I'm working on getting speakers and if nothing else Mr. Benson himself knows a ton on trading, as he was a floor trader on a few of the exchanges (as far as I understand).
I have personally been trading/investing since I was 9. I'll tell you guys more in the club- thanks for reading this and being part of the club!

Benjamin Franklin


It is possible to configure SEEK to automatically send RDF triples to a Virtuoso Repository.
Developers may also be interested in how to extend this for other triple stores - this is potentially quite simple and please contact us on our developers mailing list if you are interested.
Virtuoso is available as a Debian package, and this is the easiest way to install it.
For other distributions, or for the latest version, please follow the online documentation using the link at the end of this section.
sudo apt-get install virtuoso-opensource
Note that during the installation process, you will be asked for a password for the DBA and DAV users. We find this doesn't change the password and it remains as the defaults dba or dav - you will need to change this passwords after the installation.
Once installed you should be able to access it, on the port 8890 - localhost:8890 - Click “Conductor” at the top right to login and change the default passwords.
You may also need to set additional privileges for deleting triples. You can do this using isql-vt:
> isql-vt -U dba SQL> grant execute on SPARQL_DELETE_DICT_CONTENT to "SPARQL"; SQL> grant execute on SPARQL_DELETE_DICT_CONTENT to SPARQL_UPDATE;
For more information about setting up and configuring Virtuoso please visit virtuoso.openlinksw.com/dataspace/doc/dav/wiki/Main/
You first need to copy the file config/virtuoso-settings.example.yml to config/virtuoso-settings.yml
This file contains configurations for the environments Rails runs under - production:, development: and test:. If you don't need it configured under a given environment, just delete that section, or add disabled: true
You need to at least set up the username and password.
There are 2 graphs defined - a private graph (that contains everything) and a public graph (that only contains RDF for publicly accessible items). However, you will need to configure Virtuoso to prevent access to the private graph. By default it will be publicly accessible.
If you don't wish to create a private graph - remove the configuration private_graph.
Finally, to start generating and sending triples run the command
bundle exec rake seek_rdf:generate RAILS_ENV=production
setting the appropriate environment for RAILS_ENV. This will generated a set of background jobs, which will start generated and sending the RDF.
You can check the progress of these jobs in the Admin pages of SEEK, under Statistics and then select Job Queue from the dropdown list.


# -*- coding: utf-8 -*-
__author__ = """Chris Tabor (dxdstudio@gmail.com)"""
if __name__ == '__main__':
from os import getcwd
from os import sys
sys.path.append(getcwd())
from MOAL.helpers.display import Section
DEBUG = True if __name__ == '__main__' else False
programmed_cell_death = True
def mitosis(self):
raise NotImplementedError
def mutate(self):
raise NotImplementedError
def copy_dna(self):
raise NotImplementedError
[docs]class CancerCell(Cell):
"""Duck Typing, with a twist - it looks like a cell, moves like a cell...
but it has a little surprise!"""
programmed_cell_death = False
tissue_type = 'skin'
tissue_type = 'eyeball + teeth'
[docs]class VitalOrgan:
"""Fun side note - when an organ or part of the body is forming,
it uses cell apoptosis to effectively 'carve out' the shape by killing
off cells in a programmatic process -- amazing!
See: https://en.wikipedia.org/wiki/Programmed_cell_death
"""
[docs] def __init__(self, cells=[]):
self.cells = cells
self.differentiation_pattern = {} # This would contain data
[docs] def replenish(self, cells):
self.cells += cells
[docs] def differentiate(self):
"""Not to be confused with cell differentiation."""
print('Differentiating!')
def autophagy(self, tissue):
print('Autophagy: cleaning up old cells!')
for cell in tissue.cells:
if cell.programmed_cell_death:
print('Killing off cell!')
else:
print('I AM A CANCER CELL - I WILL NOT DIE')
if DEBUG:
with Section('Type theory - Duck Typing'):
# Okay, so here's the rundown;
# 1. New cells are created out of thin air, for something.
# 2. They are associated with a vital organ -- that is to say,
# they ARE the vital organ -- they make up the parts of it.
# 3. An autophagy manager comes along as a process, to deal with cleanup
# and delegation (a bit of a creative interpretation here).
# 4. Manager attempts to clean up at the request of the organ,
# only to find there is a hidden cancer cell hiding underneath.
apoptos = ApoptosisManager()
organ = VitalOrgan(cells=[Cell() for _ in range(5)] + [CancerCell()])
apoptos.autophagy(organ)
some_skin = Skin()
some_other_skin = Teratoma()
print(some_skin.tissue_type)
# Oh god, wtf!
print(some_other_skin.tissue_type)


Dr. Cooper joined the Department of Bioinformatics and Genomics at UNC Charlotte in 2018. She received her Ph.D. in Molecular Biology from the University of Southern California in 2011, then worked as a post-doc at the University of Miami from 2011 to 2014. She subsequently became a research associate at Clemson University, which is where she became interested in applying her background in evolutionary biology and genomics to agricultural systems.
William Voelker graduated from North Carolina State University with a B.S in Plant Biology in 2020. He is now working on earning his PhD in Bioinformatics and Computational Biology at the University of North Carolina at Charlotte. Under the guidance of Dr. Elizabeth Cooper, he is currently studying structural variant analysis and genome assembly methods in sorghum.
Eric (Yunfei) Liao is a PhD student in Bioinformatics and Computational Biology at the University of North Carolina at Charlotte. He earned his B.S and M.S in Materials Engineering in Nanchang Hangkong University in China. He got his M.S in Information Technology at UNC Charlotte in 2019. Currently, he is forecasting West Nile Virus outbreaks using environmental, geographic, and mosquito genetic data under the guidance of Dr. Elizabeth Cooper.
Jade Takakuwa graduated from UNC Charlotte with a B.S. in Biology in 2020 after switching careers from graphics design to scientific research. She is currently pursuing her M.S. in Bioinformatics at UNC Charlotte. She joined the lab in spring of 2022 and is working on annotating and finding novel gene copies in Wyeomyia smithii (the pitcher plant mosquito).
Julian Aileru is a first year Master's student in the department of Bioinformatics and Genomics. He received a B.S. in Biology in 2021 from UNC Charlotte. He joined the lab in the Spring of 2023, and currently he is studying duplication events and mutation rates in Wyeomyia Smithii genes.
Addison Harris is a junior at UNC Charlotte working on getting her undergraduate degree in Biology. She joined Dr. Cooper's lab in the Spring of 2023, and she's currently working to identify transposable element insertions and deletions relative to the reference sorghum genome and their impacts.
Cooper Lab in Big Basin Redwoods State Park, during the 2019 ASPB meeting in San Jose, CA
Wishing Lindsay a fond farewell at the Golden Owl in April 2022
Krittika and Jade's graduation in December 2022


Timing & Training alone cannot sustain technology movements over longer term.
Cultivate a culture of sustainability for technology accomplishments.
Cultivate a culture of change for continued improvement of technology accomplishments.
Eight pillars
Culture of simplicity & sustainability (SaS).
Optimize for developer happiness.
Convention over configuration (CoC).
Ideological flexibility over purity (FoP).
Progress over stability (PoS).
Value focus over technology focus (VoT).
Facts over feelings (FoF).
Idealize over Idolize (IoI).
“That's been one of my mantras - focus and simplicity. Simple can be harder than complex: You have to work hard to
get your thinking clean to make it simple. But it's worth it in the end because once you get there, you can move mountains.”
~ Steve Jobs
Culture of simplicity & sustainability (SoS)
Scalable design - excellent theory, difficult to practice.
Release & Update often.
Code towards logical & cyclomatic simplicity
Code has cost. Justify it.
Culture of simplicity & sustainability (SoS) - Cont.
Characteristics of Unsustainable environment
Primarily Reactive.
Code first, fix defects later.
Death Spiral
Characteristics of Sustainable environment
Proactive - high quality, reliability & continous improvement.
Value Creation - Continous improvement & Efficiency
Virtuous Cycle
Higher Team morale
Ability to deal with Increasing complexity & change.
“No man should have to clean up after another man’s dog.”
~ Gerald R. Ford
Convention over configuration (CoC).
Avoid unworthy recurrent deliberations & make progress in areas that really matter.
Good conventions pay dividents across wide spectrum.
Lowers the barriers of entry.
Each part is same or very similar to other areas that went before.
A place for everything & everything in its place.
Constraints liberate the most able minds.
Ideological flexibility over purity (FoP).
Composite of many Ideological choices and paradigms.
Not a championship where superior idea is declared a winner.
Together - Stronger and more capable.
Deversity in people, paradigms & thoughts.
Accept complex journey of learning as a joy, not an obstacle.
Progress over stability (PoS).
Systems has natural tendency for ossification.
Evolution will help survival and prosperity in the future.
Progress is about people and willingsness to push change.
There are no lifetime seats.
Acquire strength to debug the busted, figure it out, and move with the times.
Welcome and encourage new ideas (not ossified old ideas). Need fresh blood and fresh ideas to make better progress.
Value focus over technology focus (VoT).
Value minded choices over technology.
Sustainable value. Grow with the change.
Glorious Majestic Monolith over Simple distributed systems.
Polygot technology choices based on value creation, simplicity & sustainability.
Facts over feelings (FoF)
Identify facts vs opinions.
Deliberate opinions based on value creation & sustainability.
Quantitative measurements vs Qualitative.
Quantify
Ability to change
Sustainability - growth & technology
Value creation.
“Too often we . . . enjoy the comfort of opinion without the discomfort of thought.”
~ John F Kennedy
Idealize over Idolize (IoI)
Idealize - thoughts, ideas & paradigms.
Never idolize - thoughts, opinions ...
Ready to change the ideals.
Deliberate and look for counter points.
Welcome diversity
“Everyone should be respected as an individual, but no one idolized.”
~ Albert Einstein
“Every great dream begins with a dreamer. Always remember, you have within you the strength,
the patience, and the passion to reach for the stars to change the world.”
~ Harriet Tubman


{% extends "layout_task-list.html" %} {% block page_title %} Money Claims Prototype {% endblock %} {% block home_link %} ../../task-list {% endblock %} {% block proposition_header %} {% set my_account="1" %} {% include "includes/propositional_navigation.html" %} {% endblock %} {% block content %} {% include "includes/phase_banner_beta.html" %} {{formData | safe}} Back Do you need help paying your court fees? If you’re on a low income or get certain benefits you could get help paying your court fees (opens in new window). Yes No {% endblock %}
If you’re on a low income or get certain benefits you could get help paying your court fees (opens in new window).


This document defines the YAML format and structure used for Eth2 testing.
Ethereum 2.0 uses YAML as the format for all cross client tests. This document describes at a high level the general format to which all test files should conform.
The particular formats of specific types of tests (test suites) are defined in separate documents.
Test formats:
bls
epoch_processing
genesis
operations
sanity
shuffling
ssz_generic
ssz_static
generator
: a program that outputs one or more test-cases, each organized into a config > runner > handler > suite
hierarchy.config
: tests are grouped by configuration used for spec presets. In addition to the standard configurations,
general
may be used as a catch-all for tests not restricted to one configuration. (E.g. BLS).type
: the specialization of one single generator
. E.g. epoch processing.runner
: where a generator is a “producer”, this is the “consumer”.
runner
focuses on only one type
, and each type has only one runner
.handler
: a runner
may be too limited sometimes, you may have a set of tests with a specific focus that requires a different format.
To facilitate this, you specify a handler
: the runner can deal with the format by using the specified handler.suite
: a directory containing test cases that are coherent. Each suite
under the same handler
shares the same format.
This is an organizational/cosmetic hierarchy layer.case
: a test case, a directory in a suite
. A case can be anything in general,
but its format should be well-defined in the documentation corresponding to the type
(and handler
).case part
: a test case consists of different files, possibly in different formats, to facilitate the specific test case format better.
Optionally, a meta.yaml
is included to declare meta-data for the test, e.g. BLS requirements.The configuration constant types are:
(genesis data, timestamp) -> epoch number
, you end up needing both constants.Based on these types of changes, we model the config as a list of key value pairs, that only grows with every fork (they may change in development versions of forks, however; git manages this). With this approach, configurations are backwards compatible (older clients ignore unknown variables) and easy to maintain.
Tests should be independent of any sync-data. If one wants to run a test, the input data should be available from the YAML. The aim is to provide clients with a well-defined scope of work to run a particular set of test-suites.
File path structure:
tests/<config name>/<fork or phase name>/<test runner name>/<test handler name>/<test suite name>/<test case>/<output part>
<config name>/
Configs are upper level. Some clients want to run minimal first, and useful for sanity checks during development too. As a top level dir, it is not duplicated, and the used config can be copied right into this directory as reference.
<fork or phase name>/
This would be: “phase0”, “transferparty”, “phase1”, etc. Each introduces new tests, but does not copy tests that do not change. If you like to test phase 1, you run phase 0 tests, with the configuration that includes phase 1 changes. Out of scope for now however.
<test runner name>/
The well known bls/shuffling/ssz_static/operations/epoch_processing/etc. Handlers can change the format, but there is a general target to test.
<test handler name>/
Specialization within category. All suites in here will have the same test case format.
Using a handler
in a runner
is optional. A core
(or other generic) handler may be used if the runner
does not have different formats.
<test suite name>/
Suites are split up. Suite size (i.e. the amount of tests) does not change the maximum memory requirement, as test cases can be loaded one by one. This also makes filtered sets of tests fast and easy to load.
<test case>/
Cases are split up too. This enables diffing of parts of the test case, tracking changes per part, while still using LFS. Also enables different formats for some parts.
<output part>
E.g. pre.yaml
, deposit.yaml
, post.yaml
.
Diffing a pre.yaml
and post.yaml
provides all the information for testing, good for readability of the change.
Then the difference between pre and post can be compared to anything that changes the pre state, e.g. deposit.yaml
These files allow for custom formats for some parts of the test. E.g. something encoded in SSZ.
Some yaml files have copies, but formatted as raw SSZ bytes: pre.ssz
, deposit.ssz
, post.ssz
.
The yaml files are intended to be deprecated, and clients should shift to ssz inputs for efficiency.
Deprecation will start once a viewer of SSZ test-cases is in place, to maintain a standard of readable test cases.
This also means that some clients can drop legacy YAML -> JSON/other -> SSZ work-arounds.
(These were implemented to support the uint64 YAML, hex strings, etc. Things that were not idiomatic to their language.)
Yaml will not be deprecated for tests that do not use SSZ: e.g. shuffling and BLS tests. In this case, there is no work around for loading necessary anyway, and the size and efficiency of yaml is acceptable.
meta.yaml
If present (it is optional), the test is enhanced with extra data to describe usage. Specialized data is described in the documentation of the specific test format.
Common data is documented here:
Some test-case formats share some common key-value pair patterns, and these are documented here:
bls_setting: int -- optional, can have 3 different values:
0: (default, applies if key-value pair is absent). Free to choose either BLS ON or OFF.
Tests are generated with valid BLS data in this case,
but there is no change of outcome when running the test if BLS is ON or OFF.
1: known as "BLS required" - if the test validity is strictly dependent on BLS being ON
2: known as "BLS ignored" - if the test validity is strictly dependent on BLS being OFF
reveal_deadlines_setting: -- optional, can have 2 different values:
0: default, `process_reveal_deadlines` is ON.
1: `process_reveal_deadlines` is OFF.
A configuration is a separate YAML file. Separation of configuration and tests aims to:
The format is described in /configs
.
The constants configurations are located in:
<specs repo root>/configs/<config name>.yaml
And copied by CI for testing purposes to:
<tests repo root>/tests/<config name>/<config name>.yaml
The first <config name>
is a directory, which contains exactly all tests that make use of the given config.
The basic pattern for test-suite loading and running is:
operations > deposits
). Again, repeat for each if running all.meta.yaml
if present.Step 1 may be a step with compile time selection of a configuration, if desired for optimization. The base requirement is just to use the same set of constants, independent of the loading process.
SSZ SimpleSerialize


navbar
and dropdown
menus.
Although this isn't the standard configuration which MobileSiteOS™ uses (as seen above
and derived from Bootstrap UI v2.3.2), it should now be obvious that either are available.
Please note the dropdownV3
class names used in the example HTML.


Answer ten questions to discover which historic shipwreck most resembles you, and your possible future resting place.
Click "restart" to start the quiz over.
Are you ready to determine how you will meet your inevitable demise?
Understandable. Return when you are ready.
Are you now ready?
- Yes
- No


The selected time is not a valid
time understood by fm-timepicker.
The selected time does not lie
within the specified start and end time.
The selected time does not
lie on a time value that would fit the given time interval.
The given start time is
invalid.
The given end time is
invalid.


The short answer is:
don't.
And the simple answer is:
cout << string( 100, '\n' );
Things like PAUSE and CLS are antithetical to stream applications (or "console applications") because they violate a fundamental given:
| - The standard input and output may not necessarily be attached to a terminal. - |
There is some history to this. Before Unix and C came along, the poor saps programming on computer systems had to know how to connect with the desired I/O devices --which was often not a simple task, as each piece of hardware needed to be treated differently just to do something like, say, read a single character --or whatever you could get from the device. This made programs specific to particular pieces of hardware and often involved some complicated job setup scripts.
Unix (and consequently, C) introduced a groundbreaking concept that we take for granted today:
I/O streams are decoupled from any specific device (meaning that you can read and write characters and the OS handles all the underlying translations to and/or from specific devices) and
they are automatically opened when the program starts (meaning that the programmer doesn't have to know any particular magic to open them).
This abstraction also provided a powerful capability copied by nearly every major OS since:
I/O redirection.
| - Applications Shouldn't Control the User - |
So, putting a PAUSE or CLS in there kind of throws a wrench in all that.
 So it is fine to stick a system("PAUSE") in there so you can see it work properly. But once it is time to send it off to your professor or put it out on the internet or whatever, those kinds of demand constraints need to go, for the reasons above and also for those previously mentioned (including the fact that using system() is a positive security breach).
If I were teaching a C or C++ programming course, the very first day of class I would make it clear that anyone turning in homework with system() calls to things like PAUSE would
loose grade points.
| - Acceptable Exceptions - |
There are, of course, times when a program
should require a human (such as a fullscreen text editor), or at least recognize when one is present. A very good article that covers all the important points is
fileno(3) on C++ Streams: A Hacker's Lament
http://www.ginac.de/~kreckel/fileno/
In the case that you actually do need to manipulate the terminal directly, you should do so explicitly by using console-specific functions. I recommend the
Curses library, which works very well on a lot of platforms.
PDCurses Windows, DOS, OS/2...
http://pdcurses.sourceforge.net/
NCurses POSIX platforms (Unix, Linux, OS X...)
http://www.gnu.org/software/ncurses/
Both are highly compatible, and code written for one should work identically for the other. On most Linux systems, and many Unices, ncurses is already installed for you. Failing that
apt-get will install it for you.
Outside of a nice library like Curses, you must go straight to the OS to do things like clear the screen.
Performing a Clear Screen (CLS) in a Console Application
http://support.microsoft.com/kb/99261
Again, for POSIX platforms, if you have
terminfo installed you also have curses installed. If you are on something really ancient that only has
termcap it is still worth your while to install ncurses because it will work with whichever of the two terminal databases it finds.
Whew. Hope this helps.


Authentication key (API Key). Get your own by registering at https://secure.bytescout.com/users/sign_up.
Input File (*.pdf)
Output Image Format BMP JPEG PNG TIFF GIF
Rendering Resolution, DPI
Page Index (zero-based)


|
Contiki 2.5
|
00001 /** 00002 * \addtogroup rime 00003 * @{ 00004 */ 00005 00006 /** 00007 * \defgroup packetbuf Rime buffer management 00008 * @{ 00009 * 00010 * The packetbuf module does Rime's buffer management. 00011 */ 00012 00013 /* 00014 * Copyright (c) 2006, Swedish Institute of Computer Science. 00015 * All rights reserved. 00016 * 00017 * Redistribution and use in source and binary forms, with or without 00018 * modification, are permitted provided that the following conditions 00019 * are met: 00020 * 1. Redistributions of source code must retain the above copyright 00021 * notice, this list of conditions and the following disclaimer. 00022 * 2. Redistributions in binary form must reproduce the above copyright 00023 * notice, this list of conditions and the following disclaimer in the 00024 * documentation and/or other materials provided with the distribution. 00025 * 3. Neither the name of the Institute nor the names of its contributors 00026 * may be used to endorse or promote products derived from this software 00027 * without specific prior written permission. 00028 * 00029 * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND 00030 * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 00031 * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 00032 * ARE DISCLAIMED. IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE 00033 * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 00034 * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS 00035 * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 00036 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 00037 * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY 00038 * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 00039 * SUCH DAMAGE. 00040 * 00041 * This file is part of the Contiki operating system. 00042 * 00043 * $Id: packetbuf.h,v 1.2 2010/12/16 22:41:43 adamdunkels Exp $ 00044 */ 00045 00046 /** 00047 * \file 00048 * Header file for the Rime buffer (packetbuf) management 00049 * \author 00050 * Adam Dunkels<EMAIL_ADDRESS>00051 */ 00052 00053 #ifndef __PACKETBUF_H__ 00054 #define __PACKETBUF_H__ 00055 00056 #include "contiki-conf.h" 00057 #include "net/rime/rimeaddr.h" 00058 00059 /** 00060 * \brief The size of the packetbuf, in bytes 00061 */ 00062 #ifdef PACKETBUF_CONF_SIZE 00063 #define PACKETBUF_SIZE PACKETBUF_CONF_SIZE 00064 #else 00065 #define PACKETBUF_SIZE 128 00066 #endif 00067 00068 /** 00069 * \brief The size of the packetbuf header, in bytes 00070 */ 00071 #ifdef PACKETBUF_CONF_HDR_SIZE 00072 #define PACKETBUF_HDR_SIZE PACKETBUF_CONF_HDR_SIZE 00073 #else 00074 #define PACKETBUF_HDR_SIZE 48 00075 #endif 00076 00077 /** 00078 * \brief Clear and reset the packetbuf 00079 * 00080 * This function clears the packetbuf and resets all 00081 * internal state pointers (header size, header pointer, 00082 * external data pointer). It is used before preparing a 00083 * packet in the packetbuf. 00084 * 00085 */ 00086 void packetbuf_clear(void); 00087 00088 /** 00089 * \brief Clear and reset the header of the packetbuf 00090 * 00091 * This function clears the header of the packetbuf and 00092 * resets all the internal state pointers pertaining to 00093 * the header (header size, header pointer, but not 00094 * external data pointer). It is used before after sending 00095 * a packet in the packetbuf, to be able to reuse the 00096 * packet buffer for a later retransmission. 00097 * 00098 */ 00099 void packetbuf_clear_hdr(void); 00100 00101 void packetbuf_hdr_remove(int bytes); 00102 00103 /** 00104 * \brief Get a pointer to the data in the packetbuf 00105 * \return Pointer to the packetbuf data 00106 * 00107 * This function is used to get a pointer to the data in 00108 * the packetbuf. The data is either stored in the packetbuf, 00109 * or referenced to an external location. 00110 * 00111 * For outbound packets, the packetbuf consists of two 00112 * parts: header and data. The header is accessed with the 00113 * packetbuf_hdrptr() function. 00114 * 00115 * For incoming packets, both the packet header and the 00116 * packet data is stored in the data portion of the 00117 * packetbuf. Thus this function is used to get a pointer to 00118 * the header for incoming packets. 00119 * 00120 */ 00121 void *packetbuf_dataptr(void); 00122 00123 /** 00124 * \brief Get a pointer to the header in the packetbuf, for outbound packets 00125 * \return Pointer to the packetbuf header 00126 * 00127 * For outbound packets, the packetbuf consists of two 00128 * parts: header and data. This function is used to get a 00129 * pointer to the header in the packetbuf. The header is 00130 * stored in the packetbuf. 00131 * 00132 */ 00133 void *packetbuf_hdrptr(void); 00134 00135 /** 00136 * \brief Get the length of the header in the packetbuf, for outbound packets 00137 * \return Length of the header in the packetbuf 00138 * 00139 * For outbound packets, the packetbuf consists of two 00140 * parts: header and data. This function is used to get 00141 * the length of the header in the packetbuf. The header is 00142 * stored in the packetbuf and accessed via the 00143 * packetbuf_hdrptr() function. 00144 * 00145 */ 00146 uint8_t packetbuf_hdrlen(void); 00147 00148 00149 /** 00150 * \brief Get the length of the data in the packetbuf 00151 * \return Length of the data in the packetbuf 00152 * 00153 * For outbound packets, the packetbuf consists of two 00154 * parts: header and data. This function is used to get 00155 * the length of the data in the packetbuf. The data is 00156 * stored in the packetbuf and accessed via the 00157 * packetbuf_dataptr() function. 00158 * 00159 * For incoming packets, both the packet header and the 00160 * packet data is stored in the data portion of the 00161 * packetbuf. This function is then used to get the total 00162 * length of the packet - both header and data. 00163 * 00164 */ 00165 uint16_t packetbuf_datalen(void); 00166 00167 /** 00168 * \brief Get the total length of the header and data in the packetbuf 00169 * \return Length of data and header in the packetbuf 00170 * 00171 */ 00172 uint16_t packetbuf_totlen(void); 00173 00174 /** 00175 * \brief Set the length of the data in the packetbuf 00176 * \param len The length of the data 00177 * 00178 * For outbound packets, the packetbuf consists of two 00179 * parts: header and data. This function is used to set 00180 * the length of the data in the packetbuf. 00181 */ 00182 void packetbuf_set_datalen(uint16_t len); 00183 00184 /** 00185 * \brief Point the packetbuf to external data 00186 * \param ptr A pointer to the external data 00187 * \param len The length of the external data 00188 * 00189 * For outbound packets, the packetbuf consists of two 00190 * parts: header and data. This function is used to make 00191 * the packetbuf point to external data. The function also 00192 * specifies the length of the external data that the 00193 * packetbuf references. 00194 */ 00195 void packetbuf_reference(void *ptr, uint16_t len); 00196 00197 /** 00198 * \brief Check if the packetbuf references external data 00199 * \retval Non-zero if the packetbuf references external data, zero otherwise. 00200 * 00201 * For outbound packets, the packetbuf consists of two 00202 * parts: header and data. This function is used to check 00203 * if the packetbuf points to external data that has 00204 * previously been referenced with packetbuf_reference(). 00205 * 00206 */ 00207 int packetbuf_is_reference(void); 00208 00209 /** 00210 * \brief Get a pointer to external data referenced by the packetbuf 00211 * \retval A pointer to the external data 00212 * 00213 * For outbound packets, the packetbuf consists of two 00214 * parts: header and data. The data may point to external 00215 * data that has previously been referenced with 00216 * packetbuf_reference(). This function is used to get a 00217 * pointer to the external data. 00218 * 00219 */ 00220 void *packetbuf_reference_ptr(void); 00221 00222 /** 00223 * \brief Compact the packetbuf 00224 * 00225 * This function compacts the packetbuf by copying the data 00226 * portion of the packetbuf so that becomes consecutive to 00227 * the header. It also copies external data that has 00228 * previously been referenced with packetbuf_reference() 00229 * into the packetbuf. 00230 * 00231 * This function is called by the Rime code before a 00232 * packet is to be sent by a device driver. This assures 00233 * that the entire packet is consecutive in memory. 00234 * 00235 */ 00236 void packetbuf_compact(void); 00237 00238 /** 00239 * \brief Copy from external data into the packetbuf 00240 * \param from A pointer to the data from which to copy 00241 * \param len The size of the data to copy 00242 * \retval The number of bytes that was copied into the packetbuf 00243 * 00244 * This function copies data from a pointer into the 00245 * packetbuf. If the data that is to be copied is larger 00246 * than the packetbuf, only the data that fits in the 00247 * packetbuf is copied. The number of bytes that could be 00248 * copied into the rimbuf is returned. 00249 * 00250 */ 00251 int packetbuf_copyfrom(const void *from, uint16_t len); 00252 00253 /** 00254 * \brief Copy the entire packetbuf to an external buffer 00255 * \param to A pointer to the buffer to which the data is to be copied 00256 * \retval The number of bytes that was copied to the external buffer 00257 * 00258 * This function copies the packetbuf to an external 00259 * buffer. Both the data portion and the header portion of 00260 * the packetbuf is copied. If the packetbuf referenced 00261 * external data (referenced with packetbuf_reference()) the 00262 * external data is copied. 00263 * 00264 * The external buffer to which the packetbuf is to be 00265 * copied must be able to accomodate at least 00266 * (PACKETBUF_SIZE + PACKETBUF_HDR_SIZE) bytes. The number of 00267 * bytes that was copied to the external buffer is 00268 * returned. 00269 * 00270 */ 00271 int packetbuf_copyto(void *to); 00272 00273 /** 00274 * \brief Copy the header portion of the packetbuf to an external buffer 00275 * \param to A pointer to the buffer to which the data is to be copied 00276 * \retval The number of bytes that was copied to the external buffer 00277 * 00278 * This function copies the header portion of the packetbuf 00279 * to an external buffer. 00280 * 00281 * The external buffer to which the packetbuf is to be 00282 * copied must be able to accomodate at least 00283 * PACKETBUF_HDR_SIZE bytes. The number of bytes that was 00284 * copied to the external buffer is returned. 00285 * 00286 */ 00287 int packetbuf_copyto_hdr(uint8_t *to); 00288 00289 /** 00290 * \brief Extend the header of the packetbuf, for outbound packets 00291 * \param size The number of bytes the header should be extended 00292 * \retval Non-zero if the header could be extended, zero otherwise 00293 * 00294 * This function is used to allocate extra space in the 00295 * header portion in the packetbuf, when preparing outbound 00296 * packets for transmission. If the function is unable to 00297 * allocate sufficient header space, the function returns 00298 * zero and does not allocate anything. 00299 * 00300 */ 00301 int packetbuf_hdralloc(int size); 00302 00303 /** 00304 * \brief Reduce the header in the packetbuf, for incoming packets 00305 * \param size The number of bytes the header should be reduced 00306 * \retval Non-zero if the header could be reduced, zero otherwise 00307 * 00308 * This function is used to remove the first part of the 00309 * header in the packetbuf, when processing incoming 00310 * packets. If the function is unable to remove the 00311 * requested amount of header space, the function returns 00312 * zero and does not allocate anything. 00313 * 00314 */ 00315 int packetbuf_hdrreduce(int size); 00316 00317 /* Packet attributes stuff below: */ 00318 00319 typedef uint16_t packetbuf_attr_t; 00320 00321 struct packetbuf_attr { 00322 /* uint8_t type; */ 00323 packetbuf_attr_t val; 00324 }; 00325 struct packetbuf_addr { 00326 /* uint8_t type; */ 00327 rimeaddr_t addr; 00328 }; 00329 00330 #define PACKETBUF_ATTR_PACKET_TYPE_DATA 0 00331 #define PACKETBUF_ATTR_PACKET_TYPE_ACK 1 00332 #define PACKETBUF_ATTR_PACKET_TYPE_STREAM 2 00333 #define PACKETBUF_ATTR_PACKET_TYPE_STREAM_END 3 00334 #define PACKETBUF_ATTR_PACKET_TYPE_TIMESTAMP 4 00335 00336 enum { 00337 PACKETBUF_ATTR_NONE, 00338 00339 /* Scope 0 attributes: used only on the local node. */ 00340 PACKETBUF_ATTR_CHANNEL, 00341 PACKETBUF_ATTR_NETWORK_ID, 00342 PACKETBUF_ATTR_LINK_QUALITY, 00343 PACKETBUF_ATTR_RSSI, 00344 PACKETBUF_ATTR_TIMESTAMP, 00345 PACKETBUF_ATTR_RADIO_TXPOWER, 00346 PACKETBUF_ATTR_LISTEN_TIME, 00347 PACKETBUF_ATTR_TRANSMIT_TIME, 00348 PACKETBUF_ATTR_MAX_MAC_TRANSMISSIONS, 00349 PACKETBUF_ATTR_MAC_SEQNO, 00350 PACKETBUF_ATTR_MAC_ACK, 00351 00352 /* Scope 1 attributes: used between two neighbors only. */ 00353 PACKETBUF_ATTR_RELIABLE, 00354 PACKETBUF_ATTR_PACKET_ID, 00355 PACKETBUF_ATTR_PACKET_TYPE, 00356 PACKETBUF_ATTR_REXMIT, 00357 PACKETBUF_ATTR_MAX_REXMIT, 00358 PACKETBUF_ATTR_NUM_REXMIT, 00359 PACKETBUF_ATTR_PENDING, 00360 00361 /* Scope 2 attributes: used between end-to-end nodes. */ 00362 PACKETBUF_ATTR_HOPS, 00363 PACKETBUF_ATTR_TTL, 00364 PACKETBUF_ATTR_EPACKET_ID, 00365 PACKETBUF_ATTR_EPACKET_TYPE, 00366 PACKETBUF_ATTR_ERELIABLE, 00367 00368 /* These must be last */ 00369 PACKETBUF_ADDR_SENDER, 00370 PACKETBUF_ADDR_RECEIVER, 00371 PACKETBUF_ADDR_ESENDER, 00372 PACKETBUF_ADDR_ERECEIVER, 00373 00374 PACKETBUF_ATTR_MAX 00375 }; 00376 00377 #define PACKETBUF_NUM_ADDRS 4 00378 #define PACKETBUF_NUM_ATTRS (PACKETBUF_ATTR_MAX - PACKETBUF_NUM_ADDRS) 00379 #define PACKETBUF_ADDR_FIRST PACKETBUF_ADDR_SENDER 00380 00381 #define PACKETBUF_IS_ADDR(type) ((type) >= PACKETBUF_ADDR_FIRST) 00382 00383 #if PACKETBUF_CONF_ATTRS_INLINE 00384 00385 extern struct packetbuf_attr packetbuf_attrs[]; 00386 extern struct packetbuf_addr packetbuf_addrs[]; 00387 00388 static int packetbuf_set_attr(uint8_t type, const packetbuf_attr_t val); 00389 static packetbuf_attr_t packetbuf_attr(uint8_t type); 00390 static int packetbuf_set_addr(uint8_t type, const rimeaddr_t *addr); 00391 static const rimeaddr_t *packetbuf_addr(uint8_t type); 00392 00393 static inline int 00394 packetbuf_set_attr(uint8_t type, const packetbuf_attr_t val) 00395 { 00396 /* packetbuf_attrs[type].type = type; */ 00397 packetbuf_attrs[type].val = val; 00398 return 1; 00399 } 00400 static inline packetbuf_attr_t 00401 packetbuf_attr(uint8_t type) 00402 { 00403 return packetbuf_attrs[type].val; 00404 } 00405 00406 static inline int 00407 packetbuf_set_addr(uint8_t type, const rimeaddr_t *addr) 00408 { 00409 /* packetbuf_addrs[type - PACKETBUF_ADDR_FIRST].type = type; */ 00410 rimeaddr_copy(&packetbuf_addrs[type - PACKETBUF_ADDR_FIRST].addr, addr); 00411 return 1; 00412 } 00413 00414 static inline const rimeaddr_t * 00415 packetbuf_addr(uint8_t type) 00416 { 00417 return &packetbuf_addrs[type - PACKETBUF_ADDR_FIRST].addr; 00418 } 00419 #else /* PACKETBUF_CONF_ATTRS_INLINE */ 00420 int packetbuf_set_attr(uint8_t type, const packetbuf_attr_t val); 00421 packetbuf_attr_t packetbuf_attr(uint8_t type); 00422 int packetbuf_set_addr(uint8_t type, const rimeaddr_t *addr); 00423 const rimeaddr_t *packetbuf_addr(uint8_t type); 00424 #endif /* PACKETBUF_CONF_ATTRS_INLINE */ 00425 00426 void packetbuf_attr_clear(void); 00427 00428 void packetbuf_attr_copyto(struct packetbuf_attr *attrs, 00429 struct packetbuf_addr *addrs); 00430 void packetbuf_attr_copyfrom(struct packetbuf_attr *attrs, 00431 struct packetbuf_addr *addrs); 00432 00433 #define PACKETBUF_ATTRIBUTES(...) { __VA_ARGS__ PACKETBUF_ATTR_LAST } 00434 #define PACKETBUF_ATTR_LAST { PACKETBUF_ATTR_NONE, 0 } 00435 00436 #define PACKETBUF_ATTR_BIT 1 00437 #define PACKETBUF_ATTR_BYTE 8 00438 #define PACKETBUF_ADDRSIZE (sizeof(rimeaddr_t) * PACKETBUF_ATTR_BYTE) 00439 00440 struct packetbuf_attrlist { 00441 uint8_t type; 00442 uint8_t len; 00443 }; 00444 00445 #endif /* __PACKETBUF_H__ */ 00446 /** @} */ 00447 /** @} */


Depiction
- Various ways to depict biological networks:
- Node-Link (graph) representation
- Partitioned Node-Link representation
- Matrix representation
- Can be useful for very dense networks
- Can also map information into cells of matrix
- e.g. degree, color scale (heat map)
Data Mapping
- Mapping of data values associated with graph elements onto graph visuals
- Visual attributes
- Node fill color, border color, border width, size, shape, opacity, label
- Edge type, color, width, ending type, ending size, ending color
- Mapping types
- Continuous (numeric values)
- Discrete (categories)
- Passthrough (labels)
Data Mapping
- Avoid cluttering your visualization with too much data
- Highlight meaningful differences
- Avoid confusing the viewer
- Consider creating multiple network images
Layouts
- Layouts determine the location of nodes and (sometimes) the paths of edges
- Types:
- Simple
- Hierarchical
- layout data as a tree or hierarchy
- Works best when there are no loops
- Circular (Radial)
- arrange nodes around a circle
- could use node attributes to govern position
Layouts
- Types:
- Force-Directed
- simulate edges as springs
- may be weighted or unweighted
- Combining layouts
- Use a general layout (force directed) for the entire graph,
but use hierarchical or radial to focus on a particular portion
- Multi-layer layouts
- Partition graph, layout each partition then layout partitions
- Many, many others
Layouts
- Manual tweaks with Node Layout Tools
Layouts
- Use layouts to convey the relationships between the nodes.
- There is not one correct layout. Try different things.
- Layout algorithms may need to be “tuned” to fit your network.
Animation
- Animation is useful to show changes in a network:
- Over a time series
- Over different conditions
- Between species


synapse_io¶
Module: synapse_io
¶
Input/output functions to read and write Synapse tables.
- Authors:
- Arno Klein, 2015<EMAIL_ADDRESS>http://binarybottle.com
Copyright 2015, Sage Bionetworks (http://sagebase.org), Apache v2.0 License
Functions¶
-
mhealthx.synapse_io.
copy_synapse_table
(synapse_table_id, synapse_project_id, table_name='', remove_columns=[], username='', password='')¶ Copy Synapse table to another Synapse project.
- synapse_table_id : string
- Synapse ID for table to copy
- synapse_project_id : string
- copy table to project with this Synapse ID
- table_name : string
- schema name of table
- remove_columns : list of strings
- column headers for columns to be removed
- username : string
- Synapse username (only needed once on a given machine)
- password : string
- Synapse password (only needed once on a given machine)
- table_data : Pandas DataFrame
- Synapse table contents
- table_name : string
- schema name of table
- synapse_project_id : string
- Synapse ID for project within which table is to be written
>>> from mhealthx.synapse_io import copy_synapse_table >>> synapse_table_id = 'syn4590865' >>> synapse_project_id = 'syn4899451' >>> table_name = 'Copy of ' + synapse_table_id >>> remove_columns = ['audio_audio.m4a', 'audio_countdown.m4a'] >>> username = '' >>> password = '' >>> table_data, table_name, synapse_project_id = copy_synapse_table(synapse_table_id, synapse_project_id, table_name, remove_columns, username, password)
-
mhealthx.synapse_io.
extract_rows
(synapse_table, save_path=None, limit=None, username='', password='')¶ Extract rows from a Synapse table.
- synapse_table : string or Schema
- a synapse ID or synapse table Schema object
- save_path : string
- save rows as separate files in this path, unless empty or None
- limit : integer or None
- limit to number of rows returned by the query
- username : string
- Synapse username (only needed once on a given machine)
- password : string
- Synapse password (only needed once on a given machine)
- rows : list of pandas Series
- each row of a Synapse table
- row_files: list of strings
- file names corresponding to each of the rows
>>> from mhealthx.synapse_io import extract_rows >>> import synapseclient >>> syn = synapseclient.Synapse() >>> syn.login() >>> synapse_table = 'syn4590865' >>> save_path = '.' >>> limit = 3 >>> username = '' >>> password = '' >>> rows, row_files = extract_rows(synapse_table, save_path, limit, username='', password='')
-
mhealthx.synapse_io.
feature_file_to_synapse_table
(feature_file, raw_feature_file, source_file_id, provenance_activity_id, command, command_line, synapse_table_id, username='', password='')¶ Upload files and file handle IDs to Synapse.
- feature_file : string
- path to file to upload to Synapse
- raw_feature_file : string
- path to file to upload to Synapse
- source_file_id : string
- Synapse file handle ID to source file used to generate features
- provenance_activity_id : string
- Synapse provenance activity ID
- command : string
- name of command run to generate raw feature file
- command_line : string
- full command line run to generate raw feature file
- synapse_table_id : string
- Synapse table ID for table to store file handle IDs, etc.
- username : string
- Synapse username (only needed once on a given machine)
- password : string
- Synapse password (only needed once on a given machine)
>>> from mhealthx.synapse_io import feature_file_to_synapse_table >>> feature_file = '/Users/arno/Local/wav/test1.wav' >>> raw_feature_file = '/Users/arno/Local/wav/test1.wav' >>> source_file_id = '' >>> provenance_activity_id = '' >>> command_line = 'SMILExtract -C blah -I blah -O blah' >>> synapse_table_id = 'syn4899451' >>> username = '' >>> password = '' >>> feature_file_to_synapse_table(feature_file, raw_feature_file, source_file_id, provenance_activity_id, command_line, synapse_table_id, username, password)
-
mhealthx.synapse_io.
read_files_from_row
(synapse_table, row, column_name, out_path=None, username='', password='')¶ Read data from a row of a Synapse table.
- synapse_table : string or Schema
- a synapse ID or synapse table Schema object
- row : pandas Series or string
- row of a Synapse table converted to a Series or csv file
- column_name : string
- name of file handle column
- out_path : string or None
- a local path in which to store downloaded files. If None, stores them in (~/.synapseCache)
- username : string
- Synapse username (only needed once on a given machine)
- password : string
- Synapse password (only needed once on a given machine)
- row : pandas Series
- same as passed in: row of a Synapse table as a file or Series
- filepath : string
- downloaded file (full path)
>>> from mhealthx.synapse_io import extract_rows, read_files_from_row >>> import synapseclient >>> syn = synapseclient.Synapse() >>> syn.login() >>> synapse_table = 'syn4590865' >>> save_path = '.' >>> limit = 3 >>> username = '' >>> password = '' >>> rows, row_files = extract_rows(synapse_table, save_path, limit, username='', password='') >>> column_name = 'audio_audio.m4a' #, 'audio_countdown.m4a'] >>> out_path = '.' >>> for i in range(3): >>> row = rows[i] >>> row, filepath = read_files_from_row(synapse_table, row, column_name, out_path, username, password) >>> print(row)
-
mhealthx.synapse_io.
write_synapse_table
(table_data, synapse_project_id, table_name='', username='', password='')¶ Write data to a Synapse table.
- table_data : Pandas DataFrame
- Synapse table contents
- synapse_project_id : string
- Synapse ID for project within which table is to be written
- table_name : string
- schema name of table
- username : string
- Synapse username (only needed once on a given machine)
- password : string
- Synapse password (only needed once on a given machine)
>>> from mhealthx.synapse_io import read_synapse_table_files, write_synapse_table >>> in_synapse_table_id = 'syn4590865' >>> synapse_project_id = 'syn4899451' >>> column_names = [] >>> download_limit = None >>> out_path = '.' >>> username = '' >>> password = '' >>> table_data, files = read_synapse_table_files(in_synapse_table_id, column_names, download_limit, out_path, username, password) >>> table_name = 'Contents of ' + in_synapse_table_id >>> write_synapse_table(table_data, synapse_project_id, table_name, username, password)


335_connor4.py
class Solution:
def eatenApples(self, apples: List[int], days: List[int]) -> int:
h = []
result = 0
for i, apple in enumerate(apples):
day = days[i] + i
if apple:
heapq.heappush(h, (day, apple))
while h and h[0][0] <= i:
heapq.heappop(h)
if h:
day, apple = heapq.heappop(h)
result += 1
if apple - 1:
heapq.heappush(h, (day, apple - 1))
# print(i, result, h)
i = len(days)
while h:
while h and h[0][0] <= i:
heapq.heappop(h)
if h:
day, apple = heapq.heappop(h)
result += 1
if apple - 1:
heapq.heappush(h, (day, apple - 1))
i += 1
# print(i, result, h)
return result


Listen to some music
Do a quiz
Listen to a story about
an artist
Lush life
by Zara Larsson
Uptown Funk
by Bruno Mars
No Money
by Galantis
The Quiz
Say Stop to do something else
Say Score to get your score
You can ask me questions about the artist or
I can read about the artist
Tell me what you want to do
What do you want to ask
me about?
Some examples
- How old is the artist?
- Where was the artist born
- Is the artist single?
- How many kids does the artist have?


Connect to BIOLOGY-LPS in the Course Register.
BIOLOGY
BIOL-102 INTRO BIOLOGY B 1.5 CU GROUP 2 SECTIONS REGISTRATION REQUIRED FOR LEC, LAB FROM WITHIN THIS GROUP OF SECTIONS LIVING WORLD SECTOR 601 LEC F 5-7:30PM LLAB 10 WITMER/ZIMMERMA MAX: 80 LABORATORY 0 CU 602 LAB F 2-5PM LLAB 115 ARDIS J MAX: 20 603 LAB S 9-12NOON LLAB 101 DILKS K MAX: 20 604 LAB S 9-12NOON LLAB 117 YAN J MAX: 20 605 LAB S 9-12NOON TBA ROBINSON L MAX: 0 BIOL-201 ESSENTIALS OF CELL BIO 1 CU REGISTRATION REQUIRED FOR LEC, REC ONLY OPEN TO LPS STUDENTS 601 LEC MW 5-6:20PM WILL 1 JONES/SHUTOVA MAX: 30 RECITATION 0 CU ONLY OPEN TO LPS STUDENTS 602 REC MW 6:30-7PM WILL 1 JONES/SHUTOVA MAX: 30 BIOL-211 ESSENT MOL BIO &GENETICS 1 CU REGISTRATION REQUIRED FOR LEC, REC ONLY OPEN TO LPS STUDENTS 601 LEC TR 5-6:20PM GLAB 102 ZIMMERMAN J MAX: 30 RECITATION 0 CU ONLY OPEN TO LPS STUDENTS 602 REC TR 6:20-6:50PM GLAB 102 ZIMMERMAN J MAX: 30 BIOL-275 MICROBIOLOGY 1 CU ONLY OPEN TO LPS PB PRE-HEALTH STUDENTS 601 LEC S 9:30-11:30AM GLAB 101 SANDERS C LEC F 5-8PM GLAB 400 MAX: 0 BIOL-304 INFECTIOUS DISEASE BIO 1 CU ONLY OPEN TO LPS PB PRE-HEALTH STUDENTS 601 LEC W 5:30-8:30PM CHEM 119 SANDERS C MAX: 0 BIOL-306 HISTOLOGY 1 CU ONLY OPEN TO LPS PB PRE-HEALTH STUDENTS 601 LEC R 6:30-9:30PM LLAB 109 WEIL D MAX: 0 BIOL-354 DEVELOPMENTAL BIOLOGY 1 CU REGISTRATION REQUIRED FOR LEC, REC ONLY OPEN TO LPS STUDENTS 601 LEC MW 5-6:20PM LLAB 109 WAGNER J MAX: 30 RECITATION 0 CU 602 REC MW 6:30-7PM LLAB 109 WAGNER J MAX: 30 BIOL-404 IMMUNOBIOLOGY 1 CU 601 LEC M 6:30-9:30PM LLAB 10 CANCRO M MAX: 80 BIOL-407 CANCER CELL BIOLOGY 1 CU ONLY OPEN TO LPS STUDENTS 601 SEM W 6:30-9:30PM GLAB 100 XIA S MAX: 0 BIOL-480 ADVANCED CELL BIOLOGY 1 CU ONLY OPEN TO LPS STUDENTS 601 LEC TR 7-8:30PM GLAB 101 WITMER X MAX: 0
Return to Course & Room Roster
Comments to:
Office of the University Registrar
University of Pennsylvania
Room 221 Franklin Building
3451 Walnut Street
Philadelphia, PA 19104-6291
Phone:<PHONE_NUMBER> Fax:<PHONE_NUMBER>
<EMAIL_ADDRESS>Updated: Sat Jan 17 08:30:02 2015


Story
-
We met at Man O’War CrossFit where we had both been members for about 2 years. After crossing paths for 2 years, we finally made a connection and went on our first date after the New Year.
-
After completing her residency, Sarah took the opportunity to return to Greenville and take a pharmacist position at Greenville Health System. Daniel decided to join Sarah and take the first steps on the adventure of life together.
-
Daniel had been planning to ask Sarah to marry him on his birthday, which happened to fall on Easter Sunday. We were able to make a trip back to Kentucky for the holiday and spent a whirlwind weekend celebrating and catching up with family and friends. After Easter morning service, breakfast, and birthday gifts, Daniel proposed in front of his whole family by hiding the ring in her Easter basket.


Request for an S1 form
The deadline for this request is 4 May 2017.
{% include "../includes/S1InfoDetails.html" %}If you approve this request, when do you want the S1 to start from?
The deadline for this request is 4 May 2017.
{% include "../includes/S1InfoDetails.html" %}If you approve this request, when do you want the S1 to start from?


VoizFonica
INVOICE
Invoice No: {{ value }}
Date:{{rdate3}}
| Paid By | Number | Amount |
|---|---|---|
{{ paidby }} |
{{ mobile }} |
{{ amount }} |
Total Amount Paid
Rs {{ amount }}
Grand Total
Rs {{ amount }}