PATHER PANCHALI (SONG OF THE LITTLE ROAD) A film review by James Berardinelli Copyright 1996 James Berardinelli
RATING (0 TO 10): 8.5 Alternative Scale: ***1/2 out of ****
India, 1955 U.S. Re-Release Date: Summer 1996 Running Length: 2:05 MPAA Classification: No MPAA Rating (Nothing offensive) Theatrical Aspect Ratio: 1.33:1
Cast: Kanu Bannerjee, Karuna Bannerjee, Subir Bannerjee, Uma Das Gupta, Chunibala Devi Director: Satyajit Ray Producer: the Government of West Bengal Screenplay: Satyajit Ray, based on the novel by Bibhutibhushan Bandyopadhyay Cinematography: Subrata Mitra Music: Ravi Shankar U.S. Distributor: Merchant-Ivory/Sony Pictures Classics In Hindi with subtitles
When discussing "giants" of the non-English-speaking, international film world, four names leap immediately to mind: Ingmar Bergman, Federico Fellini, Akira Kurosawa, and Satyajit Ray. Of these men, Ray has received the least North American exposure, but, arguably, the most critical acclaim. Praise for the Indian director, who died in 1992 shortly after receiving a lifetime achievement Oscar, has been effusive from both film makers and critics. Vincent Canby, of the NEW YORK TIMES, once wrote that "an entire world is evoked" by each of Ray's films. The late Louis Malle called Ray's body of work "magical and completely unique." And James Ivory, the director of HOWARDS END and THE REMAINS OF THE DAY, has said that, after watching a Ray movie, the viewer will feel "fulfilled, enriched, maybe wiser, and wanting more."
Indeed, it is Ivory, along with his partner, Ismail Merchant, who has made this screening of PATHER PANCHALI, Ray's directorial debut, possible. With financial backing from Sony Pictures Classics, Merchant and Ivory have cleaned up, packaged, and released a series of Ray pictures for distribution in select United States theaters. Included in "The Masterworks of Satyajit Ray" is the complete APU TRILOGY, which is comprised of three of the director's early films: PATHER PANCHALI, APARAJITO, and THE WORLD OF APU. The movies, which exist on video but are not readily available, are worth searching out. Anyone who believes in the uplifting power of motion pictures will not be disappointed.
PATHER PANCHALI, Ray's first foray into the film making world, was completed in 1955, and proceeded to win the top prize at the 1956 Cannes Film Festival. It's a quiet, simple tale, centering on the life of a small family living in a rural village in Bengal. The father, Harihar (Kanu Bannerjee), is a priest and poet who cares more about his writing and spiritual welfare than obtaining wages he is owed. The mother, Sarbojaya (Karuna Bannerjee), worries that her husband's financial laxity will leave her without enough food for her two children, daughter Durga (Uma Das Gupta) and son Apu (Chunibala Devi). Harihar's family often lives on the edge of poverty, coping with the unkind taunts of their neighbors, the burden of caring for an aging aunt (Chunibala Devi), and the terrible aftermath of a natural catastrophe.
PATHER PANCHALI starts slowly, but builds inexorably towards a powerful climax as we come to know, and empathize with, the characters. Ray takes the time to create a meticulously believable world that draws the viewer in. There isn't a false note in the entire film -- not in the characterization, the dialogue, or the storyline. The emotions evoked by the events of PATHER PANCHALI are honest and true, not the contrived byproducts of manipulative formulas. Ray makes us feel with the characters, not just for them.
Most of what transpires is shown through the eyes of either Sarbojaya or Durga, and, as a result, we identify most closely with these two. Harihar is absent for more than half of the movie, and, before the penultimate scene, Abu is a mere witness to events, rather than a participant. Until the closing moments, we don't get a sense of the young boy as a fully formed individual, since he's always in someone else's shadow.
With its often-poetic black-and-white images and heartfelt method of storytelling, PATHER PANCHALI speaks intimately to each member of the audience. This tale, as crafted by Ray, touches the souls and minds of viewers, transcending cultural and linguistic barriers. The languorous pace, which initially seems detrimental, proves to be an asset -- PATHER PANCHALI would not have been the same experience had material been cut. Each scene builds upon what has come before. This is the kind of motion picture that will stay with you for hours, or perhaps even days, after you've left the theater, and that's a rare characteristic for any movie.
- James Berardinelli e-mail<EMAIL_ADDRESS>ReelViews web site: http://www.cybernex.net/~berardin
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


software engineer / developer / guy who writes computer code
whiskey drinking, tea sipping, tennis playing, wannabe entrepreneur


| speed | ||
| Scrolling speed scale. | ||
| friction | ||
| Scrolling friction, a percentage value within (1, 100) | ||
| renderByPixels | ||
| rendering by integer pixels, default set to true to improve performance. | ||
| continuousScrolling | ||
| Whether allow uper scrollable content to scroll when current scrollbar reaches edge. |


| File | Statements | Branches | Functions | Lines | |||||
|---|---|---|---|---|---|---|---|---|---|
| account-id.js | 100% | 18/18 | 100% | 8/8 | 100% | 3/3 | 100% | 18/18 | |
| array-util.js | 64.29% | 9/14 | 50% | 2/4 | 66.67% | 4/6 | 64.29% | 9/14 | |
| disable-opener-for-external-links.js | 100% | 7/7 | 75% | 3/4 | 100% | 2/2 | 100% | 7/7 | |
| excerpt-overflow-monitor.js | 87.18% | 34/39 | 68.18% | 15/22 | 100% | 5/5 | 87.18% | 34/39 | |
| is-third-party-service.js | 100% | 9/9 | 100% | 4/4 | 100% | 1/1 | 100% | 9/9 | |
| memoize.js | 91.67% | 11/12 | 75% | 3/4 | 100% | 2/2 | 91.67% | 11/12 | |
| oauth-client.js | 97.59% | 81/83 | 94.44% | 34/36 | 95.65% | 22/23 | 96.55% | 56/58 | |
| random.js | 100% | 9/9 | 75% | 3/4 | 100% | 2/2 | 100% | 9/9 | |
| scope-timeout.js | 100% | 9/9 | 100% | 4/4 | 100% | 3/3 | 100% | 9/9 | |
| session-util.js | 100% | 5/5 | 100% | 2/2 | 100% | 1/1 | 100% | 5/5 | |
| url-util.js | 100% | 13/13 | 75% | 3/4 | 100% | 2/2 | 100% | 13/13 |


Stats: 6’3”, 185 Lbs., Cauc Male, early thirties. Experimented with a large variety of substances, from the regular stuff, to the weird stuff! Experienced the mild end of addiction with some substances. Decided to back off each time before consequences outweighed benefits. Considered highly successful in most areas of my life. Never has use come close to becoming a problem in academic, occupational, or social spheres. That being said, I had decided to attempt a longitudinal outcome study (anecdotal at best) of the positive or negative results of a year long consistent dose of poppy tea used as treatment of long term pain issues.
The preparatory reading ahead of time consisted of a mountain of medical articles concerning the gamut of opiates, natural, semi, and fully synthetic. Half scared to death about the potential for serious addiction, I decided that an every other day dose would be sufficient to build up metabolites in my system, but not be so bad to taper down at the end. This way, I would have to deal with withdrawals of a significant nature and a routine revolving around scheduling doses. This was done for a simple reason, to reproduce dependence to the point of addiction, without the “addictive personality” associated with it. Simply put: how would a regular guy react to the opium tea, with easily obtained information and supplies?
The recipe is well known. For my purposes, I would grind up an entire box to homogenize the product. Use calculated in a rough way was 4.5 Tablespoons of pulverized dried material (about 4 golf ball sized poppies) every other day. Chemically speaking, I know the pH lemon thing to be of little consequence to extraction of material, but did it anyway because it seems that everyone else did. It didn’t help much with the taste.
Initial response for me was typical of an opiate naive user at recreational dose: Slight stimulation, talkativeness, pain perception changed to positive physical feelings, as well as mental elatedness and the tell tale pin point pupils: in short I was high. This was accompanied by nausea, itching, dehydration, constipation, difficulty urinating, trouble sleeping, respiration slowed (at some points waking me up). As time went on, most positive elements gradually lowered, but were always still noticeable, even towards the end. Constipation never changed.
My wife and I had discussions about personality and other changes. Changes were slight: decreased anxiety, memory retrieval slower, weight loss of about 15 Lbs over one year, need for sleep increased, motivation lowered slightly. Surprisingly no “need to get high” feelings I’d felt with other drugs before, but I was looking forward to the “every other night” dose.
OK, the end! I decided to do a taper schedule like this: From the original does of the 3 cups of material (1st and 2nd press together), down to 2 cups (after mixing the 2 presses), holding that dose for a week. Then going down each week by ½ a cup. This lasted a bit, and I used Kratom at the end to alleviate the “end of things” blues and small doses of loperamide. As a side note, Kratom works, and works well for withdrawal symptoms. My symptoms were mild with the taper, and consisted of mild diarrhea, and some increased sleep and lack of motivation. These didn’t feel bad, and they were expected. I didn’t need any time off of work and felt back to baseline within a week of the Kratom use.
Experience Reports are the writings and opinions of the individual authors who submit them.
Some of the activities described are dangerous and/or illegal and none are recommended by Erowid.


PSF: Forecasting of Univariate Time Series Using the Pattern
Sequence-Based Forecasting (PSF) Algorithm
Pattern Sequence Based Forecasting (PSF) takes univariate
time series data as input and assist to forecast its future values.
This algorithm forecasts the behavior of time series
based on similarity of pattern sequences. Initially, clustering is done with the
labeling of samples from database. The labels associated with samples are then
used for forecasting the future behaviour of time series data. The further
technical details and references regarding PSF are discussed in Vignette.
Downloads:
Reverse dependencies:
Linking:
Please use the canonical form
https://CRAN.R-project.org/package=PSF
to link to this page.


From the newsletter ...
Please accept my apologies
David Page
Cogges Parish
|
Other articles
|
Next issue
© 1999; Published in
Cogges Parish monthly newsletter
, number 241, June 1999
cogges.pcc@comlab.ox.ac.uk


readResponse
element enclosing the data requested, as in:
restSQL supports XML and JSON media types for encoding data in request and response entities (bodies), with XML being the default.
| Name | Mime Type | Default |
|---|---|---|
| XML document | application/xml | Yes |
| JSON object | application/json | No |
Request bodies are used with write operations (POST, PUT, DELETE) but not always. POST and PUT also accepts URL-encoded parameters (Content-Type: application/x-www-form-urlencoded). DELETE request bodies are optional.
Response bodies are always returned with successful execution, i.e. 200 OK. (See HTTP Status Codes for all status codes). A read operation (GET) response contains the data requested or empty set. A write operation (POST, PUT, DELETE) returns the
writeResponse
XML document or JSON object that contains the number of rows affected.
Media types are specified in the restSQL HTTP API using HTTP Standard Headers: Content-Type and Accept. These are generally set to the same values unless URL encoded params are part of a POST or PUT, or if the application desires to submit in one encoding and receive another (unusual). If you do not explicitly set the Accept header, your framework or browser will most likely insert a default for you. For example Chrome might use something like
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
, which means your response will be in XML format even if your Content-Type is JSON.
You may use the
_output
query parameter on GET requests, for example
http://host/restsql/MyResource/345?_output=application/json
. This overrides the Accept header value.
XML request documents must conform to Request.xsd and responses to Response.xsd.
readResponse
element enclosing the data requested, as in:
<readResponse> <actor actor_id="123" first_name="JULIANNE" last_name="DENCH" /> <actor actor_id="124" first_name="SCARLETT" last_name="BENING" /> <actor actor_id="125" first_name="ALBERT" last_name="NOLTE" /> </readResponse>
<readResponse> <actor actor_id="123" first_name="JULIANNE" last_name="DENCH"> <film year="2006" title="ADAPTATION HOLES" film_id="3" /> <film year="2006" title="ATLANTIS CAUSE" film_id="43" /> </actor> <actor actor_id="123" first_name="SCARLETT" last_name="BENING"> <film year="2006" title="BERETS AGENT" film_id="67" /> <film year="2006" title="BULL SHAWSHANK" film_id="105" /> <film year="2006" title="CHOCOLATE DUCK" film_id="148" /> </actor> </readResponse>
If no data is found matching the query, the document will be emtpy, as in:
<readResponse> </readResponse>
A write request is a
request
element followed by the data to write, as in:
<request> <actor actor_id="123" first_name="JULIANNE" last_name="DENCH" /> <actor actor_id="124" first_name="SCARLETT" last_name="BENING" /> <actor actor_id="125" first_name="ALBERT" last_name="NOLTE" /> </request>
writeResponse
element with the number of rows affected, as in:
<writeResponse rowsAffected="4" />
JSON objects conform to a restSQL-specific format. A read response contains an object with a single attribute of type array. The attribute is named after the parent table's plural name (or alias), as in:
{ "actors": [ { "id": "123", "first_name": "JULIANNE", "surname": "DENCH" }, { "id": "124", "first_name": "SCARLETT", "surname": "BENING" }, { "id": "125, "first_name": "ALBERT", "surname": "NOLTE" } ] }
{ "actors": [ { "actor_id": "123", "first_name": "JULIANNE", "surname": "DENCH" }, "films": [ { "year": "2006", "title": "ADAPTATION HOLES", "film_id": "3" }, { "year": "2006", "title": "ATLANTIS CAUSE", "film_id": "43" } ] }, { "actor_id": "123", "first_name": "SCARLETT", "surname": "BENING" }, "films": [ { "year": "2006", "title": "BERETS AGENT", "film_id": "67" }, { "year": "2006", "title": "BULL SHAWSHANK", "film_id": "105" }, { "year": "2006", "title": "CHOCOLATE DUCK", "film_id": "138" }, ] } ] }
If no data is found matching the query, the object array will be emtpy, as in:
{ "actors": [] }
Unlike XML, the JSON write request object is encoded the same as a read response object.
A write response cotains an object with a single attribute with the rows affected, as in:
{ "rowsAffected": "4" }


--- title: Test second post ---
This is another test post.
It's only actually used to test the archive page. Let's test a code template:


| Package | Description |
|---|---|
| com.julienviet.pgclient |
= Postgres Client for Eclipse Vert.x
== Using the client
To use Postgres Client for Vert.x add the following dependency to the _dependencies_ section of your build descriptor:
* Maven (in your `pom.xml`):
[source,xml,subs="+attributes"]
----
|
| Class and Description |
|---|
| PgBatch
A batch execution.
|
| PgClient
The entry point for interacting with a Postgres database.
|
| PgClientOptions |
| PgConnection
A connection to Postgres.
|
| PgConnectionPool
A pool of connection.
|
| PgPoolOptions
The options for configuring a connection pool.
|
| PgPreparedStatement
A postgres prepared statement.
|
| PgQuery
The binding of a
PgPreparedStatement and a set of parameters that can be executed once. |
| PoolingMode |
Copyright © 2017. All rights reserved.


{% include line.html %}
Enable Javascript To View This Page
{% include massrecent.html %}
With ♥ from {{site.name}} Team - {{ 'now' | date: "%Y" }}.


Tell your non-tech friend a story about a time you got blocked on a simple problem
The problem was to remove all of the bees from a string of words. For example if the string was:
"Help! buzz I'm buzz buzz surrounded buzz by buzz buzz bees!!"
We needed to remove all of the variations of “buzz” from the sentence. The output should look like this:
"Help! I'm surrounded by bees!!”
I thought that was easy enough, I will just split the string into words and filter out the ‘buzz’. The thing that caught me
was that buzz could be spelt like: “buzz”, “Buzz”, “BUzZ” “bizz” and so on…
I ended up writing a very big line of code to account for all the variations of buzz.. It looked something like this:
Str !== “Buzz” && str !== “buzz” && str !== “BuzZ” && str !== “BUZZ” …. Etc etc..
This is saying “word does not equal Buzz AND word does not equal buzz AND ….
That did the job but it could definitely be refactored into a more simple and elegant solution.
Solved a problem in an elegant way.
To solve the problem I had to think about how I could make all the variations of casing into one. After quite a bit of
googling I hit a match. Luckily in JavaScript there is a method that can convert a word into lowercase letters.
toLowerCase();
And well now my code looked like this..
word.toLowerCase() !== "buzz"
Convert all the words to lowercase and filter out buzz! Much nicer solution.
Even though my first solution did pass the
tests, I felt much more satisfied with the shorter and more concise second solution. I learned that there is usually always
another way to solve a problem, and refactoring code is a skill in itself.
Reflect on how confident you feel using the problem solving techniques and process:
Pseudocode
I’m not very confident using pseudocode for problem solving. I may write some pseudocode but then never read it while I am
trying to solve a problem. However I do like having pseudocode for when I come back to look at my again after a break/time
off. It saves me from reading through all the code to remember what it does.
Trying something
I often try very random approaches just to see what the outcome is. Usually it fails, but if it seems interesting or useful
I will probably do more research on that approach. Then I might go down a rabbit hole and end up having to go back to step 1.
Rubber ducky method
I have yet to use the rubber ducky method. I keep telling myself to try it, but I always forget. I’m really interested in
trying it the next time I come across a difficult problem.
Reading error messages
I skim read the error messages, the big red text is not very user friendly to look at so I don’t spend much time reading them.
Console.logging
I’m quite confident in console logging various parts of my code. I usually put them in everywhere I can, especially when it
comes to scope and accessing variables. Sometimes the execution context can get very confusing so the console helps to show
me what is happening.
Googling
I’ve been trying to improve my googling skills when it comes to coding related problems. Sometimes there can be so many
solutions to a problem and it can get very daunting seeing the google results, however it is a great tool to help with everything.
Asking your peers for help
Getting peer to peer help is one of the most effective methods in problem solving for me. Communication is an amazing ability
we have as humans, and it should be used as much as possible.
I haven't had to ask anyone for help yet. However I have looked
at my peers' code on their blog sites and it always fascinates me on everyone's creative approaches in coding and design.
I expect to be asking for a lot of help in the coming weeks.
Asking coaches for help
I’m confident in asking for help from my coaches when the time comes. They have years of insight into development and have
probably come across the same problems as me before.
 I find the act of making me
think about what I did is really helping me to solidify my learning.


Open Internet Report
Home
Explore
Rankings
Your City
Methods
Contact
Ranking
This is where ranking info will be.


- Name: Okeowo Busola
- Alias: SheWritesCode
- Gender: Female
- Age: 20
- Nationality: Nigerian
- Phone: +2348026910113
- Email<EMAIL_ADDRESS>I am 19 year old, a big sister to both of my brothers, daugther to my parents, a companion to friends and a blessing to my generation.
I live in Epe, Lagos with my family.
I love ice-cream, coding, reading, singing and solving problems.


--- title: Shuffle layout tags: [special_layouts] last_updated: November 30, 2015 keywords: shuffle, card layout, dynamic grid, doc portal, support portal summary: "This layout shows an example of a knowledge-base style navigation system, where there is no hierarchy, just groups of pages that have certain tags." permalink: mydoc_shuffle.html sidebar: mydoc_sidebar folder: mydoc --- {% if site.output == "pdf" %} {{site.data.alerts.note}} The content on this page doesn't display well on PDF, but I included it anyway so you could see the problems this layout poses if you're including it in PDF. {{site.data.alerts.end}} {% endif %} {% unless site.output == "pdf" %} {% endunless %}


|
CHANGING/MANIPULATING TEXTURES
|
This is a walk-through as to how to change and manipulate textures.
Before starting this tutorial you should first get acquainted with the basics of the "Tread3D" editor; the screen and the various commands that are available.
As in the "MAKING A BRUSH", "SAVING YOUR WORK", "HOLLOWING A BRUSH", or "GROUPING/UNGROUPING" tutorials start "Tread3D" and make a very basic hollowed brush (A room); or just open your saved file called "tutorial".
Your screen should look like the one below.
You will notice that what you have is a basic room with four walls, a ceiling and a floor.
Also, all the textures are the same.
Now, you can change the textures of an entire brush or just change the texture of a brush face.
First we will change the textures of an entire brush and then change the texture of a brush face.
Now, if you look at the "Texture Workspace" you will notice that the default texture was "e1u1/metal2_1" and therefore all your textures are this one.
The "Texture Workspace" looks like this.
First lets search for a new texture to use.
We can click on the "Browse" button or use the "Upper Bar".
The "Browse" button looks like this.
The "Upper Bar" looks like this.
You will notice that the "Lower Bar" shows "No Item" and that is because you have only used one texture.
Lets click the "Browse" button and the "Texture Browser" now appears.
In the browser all textures are viewed at 64x64 and if you want to change the viewing size just go to the size "Drop Down" display and scroll to the size desired.
These are the sizes options available.
Lets change the view size to 128x128 because the wall in the room are approximately 128x128.
The "Texture Browser" window should now look like this.
Lets pick a texture that is 128x128.
The texture chosen is "e1u1/metal6_1".
So, click on the texture in the browser.
The "Texture Browser" window should now look like this.
Now just click on the "Done" button.
The "Texture Workspace" looks like this.
You will notice in the "Texture Workspace" that the new texture shows up in the "Texture Workspace Window" and the "Upper/Lower Bar".
If you activate the "Lower Bar" you will now see both the original texture and the new texture displayed.
Now if you had used the "Upper Bar" you would have achieved the same result but this technique is not as versatile as using the 'Texture Browser".
A view of the "Upper Bar" when searching for textures is shown below.
Now lets move the 3D camera inside the room.
Click on the "Camera" button and the camera comes into view.
Adjust the camera until your view is inside the room looking at the top wall in the TopX/Y view.
Your screen should look like the one below.
Click on the "Pointer" button.
Now point and click the wall you are facing in the 3D view.
The wall should now be highlighted.
Your screen should look like the one below.
Now click on the "Paint Object" button.
Your screen should look like the one below.
Now unselect the wall by clicking on the background in the TopX/Y view.
You will see that the texture has changed but it needs to be aligned.
Your 3D view screen should look like the one below.
First, click on the wall in the 3D view to highlight it.
Second, click on the "Texture Lock" button to allow texture manipulation.
The "Texture Lock" button looks like this.
Now click on the "Face Properties" button.
You will see a new window appear.
The "Face Properties" window looks like this.
Adjust the "Shift-X" valu until the texture is aligned.
As you are adjusting the values you can see the texture actually move in the 3D view.
The "Face Properties" window now looks like this.
Now click on the "Pointer" button.
The "Face Properties" window now disappears.
Your screen should look like the one below.
Thats all there is to it.
What you have done is changed the texture on all six sides of a brush and manipulated the texture on one face of a brush.
Now lets change the texture on only one face of a brush.
The only thing that is different from above is the order in which things are done.
Now lets move the 3D camera so it faces the bottom wall in the TopX/Y view.
Adjust the camera as you did above.
Your screen should look like the one below.
The first thing to do is click on the "Face Properties" button.
Now point at the wall in the 3D view.
Finally click on the "Paint Object" button.
Now as above adjust the texture alignment.
Your 3D view screen should look like the one below.
Thats all there is to it.
What you have done is changed the texture on only one face of a brush and manipulated the texture on it.
Now resave your work.


Each paragraph describes a journey through a landscape modeled after a country’s flag, with the most obvious assignments of colors to types of terrain:
In addition, the journey follows a path that traces a number. Indexing the number into the country name produces the answer, HABITUAL.
| Map | Country | Index | Extracted Letter |
|---|---|---|---|
| Marshall Islands | 5 | H | |
| Bosnia and Herzegovina | 6 | A | |
| Brazil | 1 | B | |
| Finland | 2 | I | |
| Djibouti | 7 | T | |
| Nauru | 3 | U | |
| Kazakhstan | 2 | A | |
| Lesotho | 1 | L |


My name is Laurent Ricci, I’m the Group Engineering Manager for the Dynamics 365 for Operations SCM Team based in Copenhagen Denmark. I’m in charge of 50 software engineers building the SCM part of the Microsoft ERP system. I joined Microsoft 13 years ago as a developer in the kernel team for the same product, I led the kernel team for 4 years when we were in charge of all developer experience (compiler, interpreter, debugger etc…) in what was called Dynamics AX. I then moved to the application part of AX leading different teams (Planning, Manufacturing, SCM …). Before joining Microsoft I worked for 10 years in a consulting company in France doing projects mainly in the defense area before moving to Denmark and working 4 years building a compiler and its environment for a Sales Configuration Solution. I’m French from Paris and I relocated to Denmark 20 years ago.


Gateway
BOT
16-Feb-19 02:32 PM
[dscrdvrsc] <CryptoYeti> Hahahaha
[dscrdvrsc] <CryptoYeti> If Brexit happens I may well go and live in the EU
[dscrdvrsc] <hin5584> need help
[dscrdvrsc] <hin5584> when i log in agama i cant find my wallet seed
[dscrdvrsc] <hin5584> but i have the 23 secret words
[dscrdvrsc] <Oink> Native or light mode?
[dscrdvrsc] <hin5584> light
[dscrdvrsc] <Oink> Let’s move to #community-support
[dscrdvrsc] <Thoskk> @Oink well, as they voted in majority for the "hard fork" themselves, I don't have too much compassion for them., sorry
[dscrdvrsc] <Thoskk> actually I'm rather angry about them, because they will make things so much more complicated for the rest of the EU just because of a totally selfish thinking.
[dscrdvrsc] <Oink> True.... United States of Europe is a mile further off now....
[dscrdvrsc] <Thoskk> exactly
[dscrdvrsc] <Oink> Ca’n’t we call Trump for funding of a wall around the UK?
[dscrdvrsc] <Thoskk> or maybe just around England and Wales? I think the rest of the UK woudl appreciate
[dscrdvrsc] <Oink> I think so too... Is Hadrian’s wall still intact? (Those Romans really knew what they were doing)
[dscrdvrsc] <Thoskk> it'a only about 1 meter high... but maybe it can be used as a foundation
[dscrdvrsc] <Oink> We should call Berlin, see if we can reuse theirs....
[dscrdvrsc] <Thoskk> I think that wall already has been re-used in streets and buildings... but there may be some fence left from the GDR ... hehe
[dscrdvrsc] <Oink> Or get a cheap-ass wall from China maybe?
[dscrdvrsc] <Oink> Have you checked alibaba?
[dscrdvrsc] <Thoskk> just afraid it won't sustain the strong wind up there
[dscrdvrsc] <Oink> How about low-to-the-ground wind turbines? Anyone who crosses the border will be chopped into pieces
[dscrdvrsc] <Thoskk> not a bad idea... and use the power for mining... I'm in! ^^
[dscrdvrsc] <Oink> Me too!!!! And we’ll sell the idea to Trump for 1,000,000 BTC
[dscrdvrsc] <Thoskk> and we tell him, it's the same as Pesos, only the internet kind
[dscrdvrsc] <Thoskk> ugh, the sun is hitting my face right away... guess I'll go for a little walk, cu l8er ^^


| Number of Classes | Line Coverage | Mutation Coverage | Mutation Score |
|---|---|---|---|
| 3 | 90% | 56% | 75%
Killed: 27
Uncertain: 3
|
| Name | Line Coverage | Mutation Coverage | Mutation Score |
|---|---|---|---|
| DefaultOvhSmsConfigurer.java | 83% |
29% |
40%
Killed: 2
Uncertain: 0
|
| OvhOptionsBuilder.java | 100% |
58% |
71%
Killed: 10
Uncertain: 3
|
| OvhSmsBuilder.java | 89% |
62% |
88%
Killed: 15
Uncertain: 0
|


This is the first content div.
It has the data-name
attribute set to 1
This is the second content div.
It has the data-name
attribute set to 2
This is the third content div.
It has the data-name
attribute set to 3
plexer.js expects a document structure similar to this one:

<link rel="stylesheet" href="src/plexer.css">

1

2

3

This is the first content div.

It has the data-name attribute set to 1

This is the second content div.

It has the data-name attribute set to 2

This is the third content div.

It has the data-name attribute set to 3

Notice that the list items inside #switchboard
all have a data-content-name
attribute set, and that there's a div
inside #content
with a matching data-name
attribute set. These values can be anything as long as they match. I picked 1, 2, and 3, but that's just how I was feeling at the time.
Here's the example above in action:
It has the data-name
attribute set to 1
It has the data-name
attribute set to 2
It has the data-name
attribute set to 3
Moderately slick. Style to taste and enjoy. MIT licensed.


{% comment "License" %} % Copyright (c) 2018 ISP RAS (http://www.ispras.ru) % Ivannikov Institute for System Programming of the Russian Academy of Sciences % % Licensed under the Apache License, Version 2.0 (the "License"); % you may not use this file except in compliance with the License. % You may obtain a copy of the License at % % http://www.apache.org/licenses/LICENSE-2.0 % % Unless required by applicable law or agreed to in writing, software % distributed under the License is distributed on an "AS IS" BASIS, % WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. % See the License for the specific language governing permissions and % limitations under the License. {% endcomment %} {% for data in data_map %}
{% endfor %} {% for d in data_values %} {% for d in data.content %} {% endfor %}


Welcome
Drawing
Maps
Shared maps
Logout
My assignments:
Option 1
Option 2
Option 3
Name:
xxx
From:
xxx
Deadline:
xx-xx-xx
MapID:
xxxxxx
Description:
xyztvu


(I'm lazy so I just took this index page right off the example given by fcc - jackyef)
User stories:
1) I can pass a string as a parameter, and it will check to see whether that string
contains either a unix timestamp or a natural language date (example: January 1, 2016)
2) If it does, it returns both the Unix timestamp and the natural language form of that date.
3) If it does not contain a date or Unix timestamp, it returns null for those properties.
Example usage:
https://fcc-timestamp-api-jackyef.herokuapp.com/December%2015,%202015
https://fcc-timestamp-api-jackyef.herokuapp.com/1450137600
Example output:
{
"unix":<PHONE_NUMBER>,
"natural": "December 15, 2015"
}


--- layout: home title: "Mario Lamacchia" subtitle: "Frontend Developer" image: "/static/images/bg_home.jpg" ---


Finally switched to WebStorm from Sublime Text. Sublime is now hardly supported, as well as plugins to it.


Implementation of the Base Classes for for a Single Document Interface (MDI) Every Main-Panel is displayed in its own Frame


Introduction
Tundra is a high-performance code build system designed to give the best possible incremental build times even for very large software projects.
Its design was motivated by the games industry where projects are huge and iterative rebuilding common. In games, teams of 20-30 developers working on the same multi-MLOC codebase is not uncommon. Each second spent by a build system not building wastes productivity, especially when there are thousands of builds every day!
Design Philosphy
Here are some philosophical ideas and how they have influenced the design of Tundra.
Simple is Fast
There are two parts to Tundra: a flexible Lua configuration front-end which makes dependency graphs and a very fast build engine that only executes commands. The Lua front-end only runs when needed (such as when files have been added, or Lua files changed). The build engine can therefore run unimpeded when the programmer is iterating on a build problem.
The code has no external dependencies. Tundra uses Lua 5.1 (which is customized slightly.)
Support just enough
Many modern build systems can sync code from a plethora of version control systems, download files from HTTP and lots lots more. Tundra doesn’t do any of those things. It is a relatively simple command execution platform with a Lua configuration front-end. A smaller scope means Tundra is easier to optimize.
Utilize multi-core hardware
It is important that a build system can run multiple jobs at once. But it is equally important to utilize all cores to do other things like file signing and implicit dependency scanning. Tundra is one of very few (if any) build systems that do this whenever possible. This design gives a nice speedup to incremental builds where most of the time is spent signing and checking file metadata.
Reliably support code generation
Tundra is designed around the concept of build passes, which segment the input dependency graph into serialized regions. Dependencies (even implicit dependencies) can only point to nodes in the same or earlier passes. This design makes it easy to reliably support code generation scenarios of arbitrary complexity while still supporting fully multi-threaded execution whenever possible.
Many build systems have problems running a mix of code generation and regular
build workloads in parallel, because compilation steps might covertly try to
include generated files via #include
statements. Instead of solving this
problem by exhaustively mapping out #include
statements, Tundra forces you to
segment the order of code generation and compilation steps explicitly. This
divides the problem into two separate workloads that can execute fully in
parallel without unintended side effects.
Separate configuration and building
By default Tundra uses Lua as its scripting language, which gives it a high-performance, powerful data collection front-end for free. However, to get the maximum speed from builds, all build actions are carried out in multi-threaded native code.
It is also possible to use a custom configuration program to generate low-level input for the build engine via a JSON data file.
This clear separation between configuration and building ensures that build speed is unaffected by bad scripting and it is easier to diagnose why a build runs slowly.
Don’t guess
Tundra doesn’t go out of its way to support auto-configuration of toolsets or guessing what compiler you want to use. It assumes you can list the configurations you care for up front. This speeds up incremental builds as no time is wasted scanning for tools in the environment every time.
For a game project, there may be millions of builds between adding a new platform or configuration to a build system. Tools are also very brittle and need a specific configuration to produce working builds. The time it will take to support a new toolset will offset the time it takes to tell the build system about it by several orders of magnitude.
Hello, world
A Tundra project requires the file tundra.lua
which specifies what build
configurations are available for the project. It is analogous to a Makefile
.
Here is a sample minimal tundra.lua
file that creates a configuration
macosx-gcc
which pulls in the stock gcc
toolset. We also say that this
configuration is to be the default if nothing is specified when Tundra is run
on Mac OS X:
Build { Units = function() local hello = Program { Name = "HelloWorld", Sources = { "hello.c" }, } Default(hello) end, Configs = { Config { Name = "macosx-gcc", DefaultOnHost = "macosx", Tools = { "gcc" }, }, }, }
The funny Units
function specifies the available targets using the "unit
syntax", a set of keywords and conventions designed to describe build target in
a high-level manner. This data will typically be big for bigger projects so
it can also be put in a separate file, in which case Units can be set to a
string which is taken as a filename.
If we now run Tundra on this input, it will build our HelloWorld
executable.
The output path shows that tundra has defaulted the variant to debug
and the
subvariant to default
.
$ tundra2 Cc hello.c Program t2-output/macosx-gcc-debug-default/HelloWorld *** build success, 2 jobs run
The next mandatory step is of course to display the famous greeting:
$ t2-output/macosx-gcc-debug-default/HelloWorld
hello, world
More examples can be found in the examples
directory in the Tundra
distribution.
Installation
Installing a binary package
Binary packages for Windows are available, see the root README.md
file of the
Tundra github page.
Both installers and zip files are available. Choose the installer for a fully
automated setup, including adding Tundra to your PATH
. The binary zips are
useful for DIY installs or to check into source control.
Installing from source
Tundra can be obtained from the official GIT repository:
git://github.com:deplinenoise/tundra.git
. Tundra uses Google’s test framework
for the unit tests, which must be made available via the Git submodule
mechanism:
$ git submodule init $ git submodule update
-
On Windows, there are two options for building:
-
Use Visual Studio 2012. The solution file is
vs2012/Tundra.sln
. After building you will need to copyvs2012/x64/Release/*.exe
to abin
directory of your choice. Copy thescripts
directory so that is lives next to yourbin
directory. -
Use MinGW. It should be enough to build using
mingw32-make
. The resulting binary ends up inbuild
, and can be installed next to ascripts
directory as desired. It is also possible to run this binary right away as it will find thescripts
directory automatically from this location. This can be convenient if you plan to hack on Tundra a lot.
-
-
On Mac OS X and other Unix-like platforms, use GNU Make.
-
Type
make
to build an optimized version -
Type
make CHECKED=yes
to build a debug version. Do this if you’re hacking on the C++ core. -
Type
make install
to install Tundra into/usr/local
(you can override the path withPREFIX=/path
) -
Type
make uninstall
to uninstall Tundra -
Cross compilation for Windows is also supported:
-
Type
make CROSSMINGW=yes
to build a windows version -
Type
make CROSSMINGW=yes installer
to build a windows installer -
Type
make CROSSMINGW=yes windows-zip
to build a windows binary zip
-
-
-
On FreeBSD you might need to rebuild world with the option
WITH_LIBCPLUSPLUS=yes
added to/etc/src.conf
in order to have LLVM’s libc++ available, or hack theMakefile
a bit.
Running the tests
To test the native code, run build/t2-unittest
.
To test the Lua scripts, run build/t2-lua selftest
.
To test the build system for regression, run ./run-tests.pl build/tundra2
.
The regression test suite currently only works on Intel-based UNIX-like
platforms. You will need to have yasm
installed for the assembly include
scanning tests to work.
A bit of Tundra nomenclature
Here are some terms and definitions used in Tundra and elsewhere in this document:
-
configuration - A two-tuple value separated with a dash; usually in the format
host-toolset
. Two common examples arewin32-msvc
andlinux-gcc
. Configurations can load one or more toolsets. -
variant - A variant of a configuration; such as a with or without debugging information. Variants serve as tags to filter settings against. By default, tundra provides three variants:
debug
,production
andrelease
but these can be overridden as desired. -
subvariant - An additional axis of separation that is orthagonal to variants but serve the same purpose. By default there is only one subvariant called
default
. Tundra itself uses two subvariants to select between build with Lua files embedded (standalone
) or with Lua files in the file system (dev
). -
build id - A four-tuple
host-toolset-variant-subvariant
used to fully identify a build. Available throughBUILD_ID
in the unit environment. -
unit - A high-level declaration of a piece of software. Unit declarations appear as a syntactic elements in unit input files. Static and dynamic libraries, programs and .NET assemblies are examples of units. Unit declarations are passed through the
nodegen
layer to produce dependency graphs from the declarations. -
environment - A data structure with key-value mappings used to track configuration data inside Tundra. Sometimes refers to the OS environment.
-
toolset - A set of commands (e.g. compiler, linker and so on) that can be used to produce output files. Multiple toolsets can be loaded into a single configuration as long as there is no overlap in their settings, that is, a .NET toolset like
mono
can coexists with something likegcc
, but you can’t have twogcc
-style toolsets loaded into the same configuration at once. Use different configurations for that.
How Tundra works
A Tundra build is more complex compared to a traditional build system such as Make, mostly for performance reasons:
-
The main program (
tundra2
) is run -
The driver will check to see if the DAG data is up to date
-
If it is not, the DAG generator (by default
t2-lua
) is called automatically-
Run the project’s
tundra.lua
script to set options -
Load toolsets, syntax files and other information as required by the configuration script
-
Run the referred
Units
file (or function) in syntax mode to define the project’s build units -
Evaluate the unit declarations and generate DAG nodes
-
The DAG is saved off to a JSON file for compilation into binary data for future builds
-
-
The
tundra2
driver picks up the updated DAG data -
Any stale output files that are no longer mentioned are deleted
-
Command line targets are analyzed to figure out what to build
-
The build engine runs
-
The build state is saved for subsequent runs
The tundra.lua file
The file tundra.lua
is read by Tundra when you invoke it. This is a regular
Lua source file. Its purpose is to call the global Build
function with a
declarative input describing the build session to Tundra. The following
sections are a reference of what you can place in the Build
block.
Declarations within the block can appear in any order.
Build { -- Required Units = "...", Configs = { ... }, -- Optional Variants = { ... }, DefaultVariant = "...", SubVariants = { ... }, DefaultSubVariant = "...", ScriptDirs = { ... }, SyntaxExtensions = { ... }, Passes = { ... }, ContentDigestExtensions { ... }, Options = { ... }, }
Units (required)
The build block must be either a function, the (string) filename of a secondary file containing unit declarations, or a table of file/functions.
Each file/function is separate because it uses a custom, extensible
syntax set which is suitable to define build system input. A common
name for external unit files is "units.lua"
, but any valid filename
is OK.
If not specified, unit definitions will be loaded from a "units.lua"
file.
Configs (required)
The Configs
key should be set to an array of configurations this build system
supports. Each configuration is in turn a Config
table.
Config
Config blocks describe configuration parameters that apply to all units in the build for that configuration, such as include paths, libraries and so on.
Config { -- Required Name = "...-...", Tools = { ... }, SupportedHosts = { "..." }, -- Optional DefaultOnHost = "..." , Inherit = ..., Env = { ... }, ReplaceEnv = { ... }, Virtual = ..., SubConfigs = { ... }, }
Config Name property (required)
The name of this configuration. Configuration names must be formatted in a
dashed platform-toolset
format. These two tokens form the first two in the
quad platform-toolset-variant-subvariant
system Tundra uses to id builds.
Config SupportedHosts property (required)
The host platforms that this configuration will be generated for. Example
platform names are linux
and windows
.
Config Tools property (optional)
A list of tools this configuration uses. A tool specification is either a
string, indicating that the defaults for that tool are to be used, or a table
{ "toolname"; Foo=1, Bar=".." }
passing arbitrary options to the tool to
configure it. Tools are loaded from the tool directory list.
Projects can add their own tool script directories via a ScriptDirs
array
property in the Build
block.
Tools = { "foo", ... { "qux"; Foo = 10, Bar = "some value" }, ... }
Config DefaultOnHost property (optional)
If present, this config will be built by default when the host platform matches
the pattern. This is convenient to have the host’s native configuration build
in the default variant when you just type tundra
in the shell. This property
can also be a table of patterns to match multiple host operating systems,
useful for example if multiple host operating systems can build a common
cross compilation config and you want that configuration to be the default
across all hosts.
If no DefaultOnHost
properties are set, nothing will build by default and a
configuration must be specified on the command line.
Config Env property (optional)
If present, must be set to a table of key-value bindings to append to the
environment for this configuration. This typically includes things such as
include paths (CPPPATH
), C preprocessor defines (CPPDEFS
) and C compiler
options (CCOPTS
).
Config { Name = "foo-bar", Env = { CPPDEFS = { "FOO", "BAR=BAZ" }, CCOPTS = "-frobnicate", }, }, }
Config ReplaceEnv property (optional)
Just like the Env block describe above, but replaces the settings rather than appending them to the environment.
Config { Name = "foo-bar", Tools = { "gcc" }, ReplaceEnv = { CC = "/my/other/gcc", }, }, }
Config Inherit property (optional)
If present, must be set to a table. This table will be scanned for values if
they are not present in the Config table itself. This is useful to group common
settings between configs in external tables. These external tables can also
inherit settings further by applying a new Inherit
property.
local foo_common = { ... } local bar_common = { ..., Inherit = foo_common, } Build { Configs = { Config { ..., Inherit = foo_common, ... }, Config { ..., Inherit = bar_common, ... }, ... }, }
Config Virtual property (optional)
If specified, and set to true
, this configuration is marked as virtual and
cannot be built directly from the command line. This is useful for
configurations that only work as subconfigurations in a cross-compilation
scenario.
Config SubConfigs property (optional)
If present, must be set to a mapping of identifiers to configuration names. The
named subconfigurations will be selectable via these identifiers using the
SubConfig
selector in units. This feature enables multi-toolset builds; that
is, building parts of a program with different C compilers, or
cross-compilation where some parts of the build must be built with the target
compiler and some with the host compiler.
Configs = { Config { Name = "foo-bar", Virtual = true, }, Config { Name = "foo-baz", Virtual = true, }, ..., Config { Name = "foo-qux", SubConfigs = { abc = "foo-bar", def = "foo-baz", ... } } ... }
Variants (optional)
Specifies a list of variants and their options. If present, these variants
completely replace Tundra’s built-in variants. There must be atleast one
variant. A variant consists of a required Name
property and an optional
Options
table.
Variants = { { Name = "...", Options = { ... } } }
Variant Options
Previously, the only currently recognized option was ‘GeneratePdb’, which caused the MSVC toolset to generate debugging files in PDB format.
This option has however been superseded by the environment variable GENERATE_PDB.
If you wish to generate PDB files for all your targets, set the GENERATE_PDB variable
to anything but 0
.
Passes (optional)
The build block can contain an array of passes which can be used to place
barriers between groups of build jobs. This is required if files are generated
that can be discovered only as implicit dependencies. Passes have two
properties, Name
and BuildOrder
, both of which are required. Passes are
ordered with the lowest BuildOrder
first.
Build { ... Passes = { Foo = { Name="...", BuildOrder = 1 }, Bar = { Name="...", BuildOrder = 2 }, ... }, ... }
ContentDigestExtensions (optional)
By default Tundra computes signatures using file timestamps. If a timestamp has changed, Tundra will consider the targets out of date. Sometimes it’s useful to only consider a file changed when its content changes and ignore the timestamp. This often comes up in builds that generate lots of source files.
The ContentDigestExtensions
block can contain an array of file extensions.
Files that end in these extensions will be signed using a SHA-1 digest of their
contents instead of the traditional timestamp.
In this example, we’re specifying that C and C++ source files should be signed
using a hash of their contents rather than their timestamps. This means you can
touch
them all you want and no rebuild will occur, you’ll need to actually
modify their contents to make that happen:
Build { ... ContentDigestExtensions = { ".c", ".h", ".cpp", ".hpp", }, ... }
Options (optional)
The Options
block is used to set advanced build engine options.
Currently the only options is MaxExpensiveJobs
which limits the maximum
number of concurrent "expensive" jobs. If your build includes heavy link steps
which might trash the system’s virtual memory reserves when run concurrently,
this option will constrain the parallelism of those jobs, and your swap file
will thank you.
To flag a DAG node as expensive, pass Expensive=true
to the dag node creator.
Currently linking programs and shared libraries is considered expensive by
default.
If MaxExpensiveJobs
is not specified, Tundra will run as many expensive jobs
as there are build threads — that is, there’s no limit.
Build { ... Options = { MaxExpensiveJobs = 2, }, ... }
Unit Syntax
This section describes the default syntax elements that are available for use in the units file. You can add your own unit syntax via extension.
Configuration Filtering
It is often desirable to include various bits of data for a certain configuration only, for example to include a source file only in the debug build of a program, or to include certain libraries only for a specific toolset. Tundra has a general mechanism called configuration filtering which supports this.
Configuration filtering uses the key-value part of a list to introduce a key
Config
into the list. The Config
key can be set to either a single pattern
string or a list of patters. The items in the list will then be included only
when one of the config patterns match:
... { "foo.c"; Config = "*-*-debug" } ... ... { "bar.c", "qux.c"; Config = { "*-foo-*", "*-bar-*" } ...
In order to combine multiple options all filtered lists can be nested
arbitrarily; the filtering process flattens these lists. The following example
results in foo.c
always being included, while bar.c
is only included in
debug builds, and foo-gcc.c
is included if the toolset matches gcc
or
mingw
. So for the linux-gcc-debug
configuration all three files will be
included.
{ "foo.c", { "bar.c"; Config = "*-*-debug" }, { "foo-gcc.c"; Config = { "*-gcc-*", "*-mingw-*" }, }
Native Units
Native units are implemented by the tundra.syntax.native
module in
conjunction with a toolset script (such as gcc
, msvc
, and others) and
provide support for building shared and static libraries as well as executables
with C, C++ and Objective-C tools. These unit types are selected through the
following keywords:
-
Program
- specifies a program -
StaticLibrary
- specifies a static library (archive) -
SharedLibrary
- specifies a shared library (dll) -
ExternalLibrary
- specifies an "external library" (a collection of settings) -
ObjGroup
- a set of object files (a static library, without the library part)
All these follow the same synopsis:
<unit type> { -- required Name = "...", -- optional Config = ..., Target = ..., Propagate = { ... }, SourceDir = "...", Sources = { ... }, -- config filtered Depends = { ... }, -- config filtered Defines = { ... }, -- config filtered Libs = { ... }, -- config filtered Frameworks = { ... }, -- config filtered }
Native Unit Name property (required)
The Name
property must always be set to a unique name. These names are
exposed on the command line (e.g. tundra foo
will build the unit foo
) and
are also used as stems when computing output filenames. For example, a
Program
unit bar
might end up as bar.exe
on Windows.
Stay away from funny characters in the names, alphanumeric is a safe bet.
Native Unit Config property
Specifies what configuration(s) this unit will be present in. Configuration
pattern matching is applied as usual. For example, to include a unit only in
debug, you could say: Config = "*-*-debug"
and to include a unit only for two
toolsets you could say Config = { "foo-bar-*", "baz-qux-*" }
.
When a unit is filtered out like this it is replaced by a null node in the DAG, but it will still be present so there’s no need to remove it from depenency lists.
Native Unit Propagate property
A nested block of settings to be propagated onto units that depend on this
unit. This is mostly useful for the ExternalLibrary
unit type which serves as
a bag of settings, but it can occasionally be useful with other unit types such
as shared libraries to push say a certain define into the compilation options
of everyone who links to this library. The propagate block can contain Libs
,
Defines
, and so on.
<unit type> { ... Propagate = { ... Key = { Value, Value, ... }, } }
For example, to push a define ZLIB_DLL
onto users of a library, one might use
the following:
SharedLibrary { Name = "zlib", Sources = { ... }, Propagate = { Defines = { "ZLIB_DLL" }, } }
Native Unit SourceDir property
If present, specifies a prefix to be applied to all files in the Sources
list.
Native Unit Sources property
An arbitrarily nested list of source files and filters. Elements in the lists can be either strings which are taken to be source files, or nodes, in which case their output files are used. It is therefore possible to call source generators in this block and then include their output files as inputs directly to the unit.
Native Unit Depends property
A list of unit names which are the dependencies of this unit. Depending on a
library unit has the side effect of linking with that archive. All Propagate
blocks from dependencies will be applied to the depending unit.
Native Unit Defines property
A list of C preprocessor defines (strings), either of the style "FOO"
or "FOO=BAR"
.
Native Unit Libs property
A list of external libraries to be fed to the linker. Typically very platform specific and thus it is common that every lib is wrapped in a configuration block, like this:
Libs = { { "kernel32.lib"; Config = { "win32-*-*", "win64-*-*" } }, { "pthread", "m"; Config = "linux-*-*" }, }
Native Unit Frameworks property
This is a Mac OS X-only feature to specify frameworks to include from and link against. Currently these is no way to select a version, so the list includes only framework names as strings.
C# Units
Tundra has basic support for building C# .NET assemblies. The following unit types are supported:
-
CSharpExe
- Builds a C# executable -
CSharpLib
- Builds a C# library (dll)
<unit type> { -- required Name = "...", -- optional Config = ..., SourceDir = "...", References = { ... }, -- config filtered Sources = { ... }, -- config filtered Depends = { ... }, -- config filtered }
Rust Units
Tundra has basic support for Rust programs, crates and shared libraries. The following unit types are supported:
-
RustProgram
- Builds a Rust executable -
RustCrate
- Builds a Rust create -
RustSharedLibrary
- Builds a Rust library (dll)
<unit type> { -- required Name = "...", -- name must match name in Cargo.toml CargoConfig = "...", Sources = { ..., "path/to/project/build.rs" }, -- optional Depends = { ... }, -- config filtered }
Tundra will call Cargo to build Rust projects so a Cargo.toml needs to be configured (which is the standard way to setup Rust projects) Cargo doesn’t support command-line args for linking libs so Tundra will set some env variables that a Cargo build script that will use to link with the correct libs.
The build.rs will need to look like this (if you use your own the following code needs to be added)
use std::env;
fn main() {
let tundra_dir = env::var("TUNDRA_OBJECTDIR").unwrap_or("".to_string());
let libs = env::var("TUNDRA_STATIC_LIBS").unwrap_or("".to_string());
let native_libs = libs.split(" ");
println!("cargo:rustc-link-search=native={}", tundra_dir);
for lib in native_libs {
println!("cargo:rustc-link-lib=static={}", lib);
println!("cargo:rerun-if-changed={}", lib);
}
}
It is also possible to override the Cargo command line and add flags to rustc
Env = { -- Extra cargo options RUST_CARGO_OPTS = { { "..."; Config = "..." }, }, -- Extra flags for rustc, this shows how to prefer-dynamic linking RUST_OPTS = "-C prefer-dynamic" }
This can be useful for using Cargo’s built-in support for testing or enabling more verbose output for example.
In the examples/rust directory in the Tundra distribution there is examples that shows how this is used in practice.
Notice about Windows: Due to a bug that was detected in Cargo when implementing this feature Rust 1.7+ (Beta) is required on Windows.
Syntax Extensions
Tundra provides a small set of syntax extensions by default. To use syntax
extensions, simply require
their Lua package names in your units.lua
or
tundra.lua
file. To add your own directories to the require
search path,
refer to the ScriptDirs
option.
File Globbing
The tundra.syntax.glob
extension provides file globbing (pattern matching
over filenames.) It is a convenient way to use the filesystem as the index of
what files to build rather than to manually type every file out in the
Sources
list. You can also combine the two for greater control by mixing
globs and filenames.
Globs come in two versions, Glob
and FGlob
.
Glob { -- required Dir = "...", Extensions = { ".ext", ... }, -- optional Recursive = false, -- default: true }
Glob
works by scanning Dir
for files matching any of the extensions passed
in the Extensions
list. By default, it will recurse into subdirectories, but
you can disable this behaviour by passing Recursive = false
. In this example
we’re getting all .c
and .cpp
files from my_dir
.
Program { ... Sources = { Glob { Dir = "my_dir", Extensions = { ".c", ".cpp" } } }, ... }
Sometimes you want to get the files from the file system but some of them are
only to be compiled for specific configurations. A common scenario is when
there are platform-specific subdirectories with source files for that platform
only. FGlob
extends Glob
and adds a list of filters to apply after the file
list has been retrieved:
FGlob { -- required Dir = "...", Extensions = { ".ext", ... }, Filters = { { Pattern = "...", Config = "..." }, ... }, -- optional Recursive = false, -- default: true }
The Pattern
attributes are regular Lua patterns that are matched against the
relative filename returned by the glob. To make patterns portable (and to save
typing), globs always return their filenames with forward slashes. In this
example, we’re tagging files in the debug
directory for a specific
configuration only, and we’re tagging files with win32
anywhere in the
filename for that platform:
Program { ... Sources = { FGlob { Dir = "my_dir", Extensions = { ".c", ".cpp" }, Filters = { { Pattern = "/debug/"; Config = "*-*-debug" }, { Pattern = "win32"; Config = "win32-*-*" }, { Pattern = "[/\\]_[^/\\]*$"; Config = "ignore" }, } } }, ... }
If you wish to exclude files based on a pattern you can specify a configuration
that doesn’t exist. In the above example the pattern [/\]_[^/\]*$
will ignore all
files where the file name starts with _
.
The initial seperator is necessary as tundra passes the full path before applying the filter (note: we need a character class that matches both POSIX and Win32 style paths if we want this to work on all platforms).
Lua patterns are not regular expressions but they are closely related. Instead
of using backslash, %
is used to reference predefined character classes or
escape reserved characters but there’s no support for repetitions of captures
or alternations.
Parser Generation (Bison & Flex)
To run bison
and flex
to generate parsers and lexers, import the
tundra.syntax.bison
syntax extension. The extension doesn’t assume any
particular name or path to either bison
or flex
so you must define them
through the environment:
... Env = { BISON = "bison", -- specify your own path if needed BISONOPT = "", -- specify addtional options if needed FLEX = "flex", -- specify your own path if needed FLEXOPT = "", -- specify addtional options if needed }, ... Program { ... Sources = { Bison { Source="grammar.y", TokenDefines = true, Pass = "SomePass" }, Flex { Source="lexer.l", Pass = "SomePass" }, }, ... }
Both generators take Source
and Pass
arguments which are self-explanatory.
The TokenDefines
option controls whether bison should generate an additonal
header with token defines. This must be controlled by the generator so that
Tundra knows about this additional output file.
Functional Composition
Because unit keywords map to Lua functions, you can easily create convenience functions on top of them. For example, say that you have many different static libraries, each following the exact same pattern. Rather than repeating all those declarations, use a function to remove the duplication:
local function dolib(name) return StaticLibrary { Name = name, Sources = { Glob { Dir = name, Extensions = { ".c" } } }, } end -- we can now say: dolib "foo" dolib "bar" dolib "baz" -- or even: for _, name in ipairs { "foo", "bar", "baz" } do dolib(name) end
Unit Return Values
Whenever you invoke a unit function such as StaticLibrary
, the return value
is a data structure that can be used wherever a name or reference to that
library is required. This removes the need to use strings. You should prefer
this style as it is less error prone and slightly faster.
local mylib = StaticLibrary { ... } local otherlib = StaticLibrary { ... } Program { Name = "main", -- ... Depends = { mylib, otherlib }, }
The Environment
Tundra uses a hierarchical key-value environment to store information used to build the commands to run. This design shares some properties with both Makefile and Jam variables and the SCons environment.
Values are always stored as lists (in this way the environment is similar to Jam variables).
Environment strings are typically set in the tundra.lua
file and in toolset
scripts but can also be set freely on units (which have their own environments
derived from the global one.)
The basic environment
With no tools or platform settings loaded, the following keys are always available:
-
OBJECTROOT
- specifies the directory in which variant-specific build directories will be created (default:tundra-output
) -
SEP
- The path separator used on the host platform
Interpolation
Basic interpolation is written $(FOO)
and just fetches the value associated
with FOO
from the environment structure. If FOO
is bound to multiple
values, they are joined together with spaces.
Interpolation Options
Tundra includes a number of interpolation shortcuts to build strings from the
environment. For example, to construct a list of include paths
from a environment variable CPPPATH
, you can say $(CPPPATH:p-I)
.
| Syntax | Effect |
|---|---|
|
Convert to forward slashes ( |
|
Convert to backward slashes ( |
|
Convert to native path slashes for host platform |
|
Convert to upper case |
|
Convert to lower case |
|
filenames: Only keep the base part of a filename (w/o extension) |
|
filenames: Only keep the filename (w/o dir) |
|
filenames: Only keep the directory |
|
Prefix all values with the string |
|
Suffix all values with the string |
|
Select the item at the (one-based) |
|
Join all values with |
|
Suffix all values with |
|
Prefix all values with |
These interpolation options can be combined arbitrarily by tacking on several options. If an option parameter contains a colon the colon must be escaped with a backslash or it will be taken as the start of the next interpolation option.
 Here’s an example of how the generic C toolchain inserts compiler options dependening on what variant is currently active:
$(CCOPTS_$(CURRENT_VARIANT:u))
This works becase the inner expansion will evalate CURRENT_VARIANT
first
(say, it has the value debug
). That value is then converted to upper-case and
spliced into the former which yields a new expression $(CCOPTS_DEBUG)
which
is then expanded in turn.
Used with care this is a powerful way of letting users customize variables per configuration and then glue everything together with a simple template.
Environment Variables
These environment variables apply to C-based toolsets:
-
CPPPATH
- A list of search directories for include files -
CPPDEFS
- A list of preprocessor definitions -
LIBS
- A list of libraries to link with -
LIBPATH
- A list of search directories for library files -
CC
- The C compiler -
CXX
- The C++ compiler -
LIB
- The program that makes static libraries (archives) -
LD
- The linker -
CCOPTS
- Common C compiler options for all configurations -
CCOPTS_<config>
- Compiler C options for variant<config>
, such asCCOPTS_DEBUG
,CCOPTS_RELEASE
. -
CXXOPTS
- Common C++ compiler options for all configurations -
CXXOPTS_<config>
- Compiler C++ options for variant<config>
, such asCXXOPTS_DEBUG
,CXXOPTS_RELEASE
. -
CCCOM
- Command line for C compilation -
CXXCOM
- Command line for C++ compilation -
PCHCOMPILE
- Command line for precompiled header compilation -
PROGOPTS
- Options specific to linking programs -
PROGCOM
- Command line to link a program -
LIBOPTS
- Options specific to creating a static library (archive) -
LIBCOM
- Command line to create a static library (archive) -
SHLIBOPTS
- Options specific to creating a shared library -
SHLIBCOM
- Command line to create a shared library -
FRAMEWORKS
- (OS X) Frameworks to include and link with -
AUX_FILES_PROGRAM
,AUX_FILES_SHAREDLIBRARY
- List of patterns that expand to auxilliary files to clean for programs, shared libraries. Useful to clean up debug and map files.
These environment variables apply to .NET-based toolsets:
-
CSC
- The C# compiler -
CSC_WARNING_LEVEL
- The C# warning level -
CSLIBS
- Assembly references -
CSRESOURCES
- Resource file references -
CSCOPTS
- Common options -
CSPROGSUFFIX
- The suffix of generated programs, by default.exe
-
CSLIBSUFFIX
- The suffix of generated libraries, by default`.dll` -
CSRESGEN
- The resource compiler -
CSCLIBCOM
- Command line to generate a library -
CSCEXECOM
- Command line to generate an executable
Toolsets
This section tries to document the stock toolsets that come included with Tundra.
generic-cpp
This isn’t really a toolset you would import explicity, it is a base layer the other tools drag in to set up defaults. It has functionality to set up preprocessor scanners, registers functions to implicitly compile source files to object files and such. All other C toolsets import this toolset.
gcc
The gcc
toolset is a simple GCC toolset that only uses basic options and does
nothing fancy. It is suitable for run-of-the-mill UNIX clones such as Linux,
BSD but also works well for command-line programs on Mac OS X.
It formats include paths with -I
, preprocessor defines with -D
and so on.
It tries to run ar
to create static libraries and there is no support for
dynamic libraries.
gcc-osx and clang-osx
gcc-osx
extends the gcc
toolset by adding Mac OS X specific options for
frameworks and shared libraries (dylib). clang-osx
is just like gcc-osx
but
uses the CLang frontend rather than GCC.
msvc
This toolset uses a cl.exe
from the environment. It is suitable for direct
use if you want to run with a local MSVC compiler that is already in your path.
msvc-vs2008
This toolset imports the msvc
toolset but can locate and set up the Visual
Studio 2008 compiler from the registry and explicitly select between 32 and
64-bit versions of the compilers. This gives two advantages:
-
You can just run tundra without setting up the environment with a compiler (e.g. through the "Visual Studio Command Prompt" shortcut)
-
You can build for multiple target architectures at the same time, for example build both x86 and x64 code in batch.
This toolset supports two options:
-
HostArch
: one ofx86
,x64
oritanium
; selects the host architecture of the compiler binaries. Defaults to x64 on 64-bit machines, x86 on 32-bit machines. -
TargetArch
: one ofx86
,x64
oritanium
; selects the target architecture of the compiler binaries. Defaults tox86
.
Here’s an example of how this toolset can be configured for an explicit target architecture:
Tools = { { "msvc-vs2008"; TargetArch = "itanium", HostArch = "x86" }, -- ... }
Extending Tundra
Tundra can be extended in three ways:
-
By adding a toolset, you can teach Tundra how to invoke a variation of a standard toolchain, such as C/C++ or .NET. A toolset configures the environment for building.
-
By adding syntactic extensions that aid in writing
units.lua
input. A good example of this is theGlob
helper which transforms a directory and a set of file extensions into a list of source files. Syntactic helpers likeGlob
operate transparently and you can always get the same results by hand. -
By adding unit extensions that implement build actions. Unit extensions can range from simple (running a single custom action) to complex (multiple nested steps that pipe build results between each other).
Adding toolsets
Toolsets configure a variation of an existing toolset implementation. Currently the following toolset types can be created:
| Language | Base toolset | Unit driver | Examples |
|---|---|---|---|
Assembly |
|
|
|
C and C++ |
|
|
|
.NET |
|
|
|
Toolset creation typically involves deriving from a base toolset script that
provides you with the common glue for that toolchain type. For example, the
generic-cpp.lua
script sets up the implicit build actions for C and C++
files, knows how to configure header scanning and so on. The derived toolset in
the C family mostly configure the environment and possibly query the machine
for compiler/tool locations.
Assembly language is currently implemented as an implicit make action that can convert assembly files to object files, and this needs a C toolset for linking as well. It is typically the case that you combine C and Assembly anyway, so this is rarely a problem. If you new toolset is designed to interop with other native tools, this might be one way to do it.
If you are trying to add a completely new language toolchain, you will probably
have to implement a new unit extension set for that toolchain too. This
extension would provide the right primitives to work with your toolset, much
like StaticLibrary
and Program
are appropriate for the native toolchain.
Adding syntax extensions
Syntax extensions are a convenience to the build file writer.
Lua syntax modules
Here is a skeleton syntax extension module to start from:
module(..., package.seeall) local decl = require "tundra.decl" local function foo(args) return { -- Replacement data goes here C = args.A + args.B } end -- Add functions to the parser, you can add more than one here decl.add_function("Foo", foo)
Basically the functions you add work as macro transformers. After loading the
syntax extension above, Foo
is exposed as a call to your function. The
parsing frontend will substitute whatever you return from foo
for the call’s
body. Using the above example Foo { A = 1, B = 2 }
will be replaced by
{ C = 3 }
.
Using DefRule to define custom build rules
DefRule is a declarative way to introduce new DAG-building primitives,
typically by calling out to external tools. Here is a simple example, taken
from the generator-simple
example:
local common = { Env = { GENSCRIPT = "generate-file.py", }, } Build { Units = function() -- A rule to call out to a python file generator. DefRule { Name = "GenerateFile", Pass = "CodeGeneration", ConfigInvariant = true, Command = "python $(GENSCRIPT) $(<) $(@)", ImplicitInputs = { "$(GENSCRIPT)" }, Blueprint = { Input = { Type = "string", Required = true }, Output = { Type = "string", Required = true }, }, Setup = function (env, data) return { InputFiles = { data.Input }, OutputFiles = { "$(OBJECTROOT)/" .. data.Output }, } end, } local testprog = Program { Name = "testprog", Sources = { "main.c", -- Generate a source file, feed the .c file back into the unit GenerateFile { Input = "data.txt", Output = "data.c" }, } } Default(testprog) end, Passes = { CodeGeneration = { Name="Generate sources", BuildOrder = 1 }, }, Configs = { -- ... }, }
Adding unit extensions
Unit extensions hook capture data during parsing which can later be transformed
into DAG nodes for building. These are more complex than DefRule
invocations,
but can do anything.
To create one, start with this template script:
module(..., package.seeall) local nodegen = require "tundra.nodegen" -- Create a metatable for this evaluator local _mt = nodegen.create_eval_subclass {} -- Describe the syntactic form of the unit. This describes the data that is -- passed into create_dag below after checking. local blueprint = { Bar = { Type = "string", Help = "The all-important Bar string", Required = true }, Sources = { Type = "source_list", Help = "List of sources", Required = true }, Frob = { Type = "filter_table", Help = "Optional bag of data" }, -- ... } -- This function will be called once for every invocation, for each -- configuration in the build. -- -- env - The unit's private environment -- data - Transformed invocation data according to blueprint -- deps - Dependencies picked up through invocation -- (e.g. nested build jobs from sources and such) function _mt:create_dag(env, data, deps) return env:make_node { Label = "Foo $(@)", Action = "$(MYACTION)", Inputs = ..., Outputs = ..., ImplicitInputs = ..., Dependencies = deps, } end -- Add evaluator nodegen.add_evaluator("Foo", _mt, blueprint)
In the metatable passed to nodegen.create_eval_subclass
you can tag on a few
additional parameter that control the data transformation functionality in the
underlying layer.
If you include a key DeclToEnvMappings
, the nodegen will accept shortcut
mappings directly to environment data. This is how Defines
maps to CPPDEFS
in the native toolset, for example.
local _native_mt = nodegen.create_eval_subclass { DeclToEnvMappings = { Libs = "LIBS", Defines = "CPPDEFS", Includes = "CPPPATH", Frameworks = "FRAMEWORKS", LibPaths = "LIBPATH", }, }
The blueprint mechanism saves you from having to validate user input in your build function. In addition to the keys you list for your unit, the following keys are always added for consistency:
| Key | Description |
|---|---|
|
Implements environment/keyword propagation to dependencies |
|
Environment data to append |
|
Environment data to replace |
|
List of unit dependencies |
|
The pass the unit should build in |
|
An alternate source directory, used for all |
|
Configuration filter |
|
Sub-configuration filter |
This means you should never list them in your blueprint as they are always
added to all units. They are handled internally in the nodegen
layer but you
are welcome to reading the data in your create_dag
implementation, especially
Pass
and Depends
are often useful.
When filling in your data blueprint, the following types are supported:
| Type name | Accepted values |
|---|---|
|
Any string value |
|
Boolean |
|
Any table value, or single string which will be wrapped in table |
|
Table which will be configuration filtered |
|
Table which is taken to contain source files (implicit actions will be run).
Pass in the name of an environment variable in |
|
A valid pass name string |
|
A list of names or unit references |
Data is transformed before being passed to the create_dag
function:
-
filter_table
data is filtered for the current build id (BUILD_ID
in the env). -
source_list
data becomes a list of filenames that might have been derived through multiple steps of implicit compilation steps. If other nodes are involved in producing these files, they will appear in thedeps
parameter. -
pass
data becomes a guaranteed valid pass object, ornil
meaning the default pass. This is intended so you can just send it straight through toenv:make_node
. -
depends
data is transformed into a list of unit data references.
The new unit we have defined above can now be used like this wherever a unit is called for:
local f = Foo { Bar = "meh", Sources = { ... }, -- ... }


Horror Game
Chapter One
The player begins coming home from being outside. It won't be explicit as to what
the player character was doing, so the player can fill that in themselves. The player will
come home to a normal home, and will use this time to get used to the game. The player
will be able to interact with different things, and explore the home completely. Once the
player is done, they have the option to go to sleep in the master bedroom. This will
officially begin the game.
Chapter Two
The player will wake up in the middle of the night. Everything will be drastically different,
but they will be in the same home. Everything looks damaged, old, ignored, and there are weird
scratching sounds at the door. All of this will be displayed as a cutscene. As the player
character gets out of bed, the player gains control again, and a monster will break through
the door. The player will need to escape the room.
After escaping, the player will then need to solve a series of puzzles in order to figure out
what is going on. At one point, the player will find a weapon and will be able to fight back
against the monsters, but ammo will be extremely limited.


A 128 bit number used to represent assets in a networking context.
More...
|
| void | Reset () |
| | Resets the value of a NetworkHash to zero (invalid). More...
|
| |
| bool | IsValid () |
| | A valid NetworkHash has a non-zero value. More...
|
| |
| override string | ToString () |
| | Returns a string representation of a NetworkHash object. More...
|
| |
A 128 bit number used to represent assets in a networking context.
◆ HexToNumber()
| static int UnityEngine.Networking.NetworkHash128.HexToNumber |
( |
char |
c | ) |
|
|
inlinestatic |
◆ IsValid()
| bool UnityEngine.Networking.NetworkHash128.IsValid |
( |
| ) |
|
|
inline |
A valid NetworkHash has a non-zero value.
- Returns
- True if the value is non-zero.
◆ Parse()
| static NetworkHash128 UnityEngine.Networking.NetworkHash128.Parse |
( |
string |
text | ) |
|
|
inlinestatic |
This parses the string representation of a NetworkHash into a binary object.
using UnityEngine; using UnityEngine.Networking;
class HashTest : MonoBehaviour { const string assetString = "0176acd452adc180"; NetworkHash128 assetId = NetworkHash128.Parse(assetString);
void Start() { Debug.Log("asset:" + assetId); } }
- Parameters
-
| text | A hex string to parse. |
- Returns
- A 128 bit network hash object.
◆ Reset()
| void UnityEngine.Networking.NetworkHash128.Reset |
( |
| ) |
|
|
inline |
Resets the value of a NetworkHash to zero (invalid).
◆ ToString()
| override string UnityEngine.Networking.NetworkHash128.ToString |
( |
| ) |
|
|
inline |
Returns a string representation of a NetworkHash object.
- Returns
- A hex asset string.
◆ i0
| byte UnityEngine.Networking.NetworkHash128.i0 |
◆ i1
| byte UnityEngine.Networking.NetworkHash128.i1 |
◆ i10
| byte UnityEngine.Networking.NetworkHash128.i10 |
◆ i11
| byte UnityEngine.Networking.NetworkHash128.i11 |
◆ i12
| byte UnityEngine.Networking.NetworkHash128.i12 |
◆ i13
| byte UnityEngine.Networking.NetworkHash128.i13 |
◆ i14
| byte UnityEngine.Networking.NetworkHash128.i14 |
◆ i15
| byte UnityEngine.Networking.NetworkHash128.i15 |
◆ i2
| byte UnityEngine.Networking.NetworkHash128.i2 |
◆ i3
| byte UnityEngine.Networking.NetworkHash128.i3 |
◆ i4
| byte UnityEngine.Networking.NetworkHash128.i4 |
◆ i5
| byte UnityEngine.Networking.NetworkHash128.i5 |
◆ i6
| byte UnityEngine.Networking.NetworkHash128.i6 |
◆ i7
| byte UnityEngine.Networking.NetworkHash128.i7 |
◆ i8
| byte UnityEngine.Networking.NetworkHash128.i8 |
◆ i9
| byte UnityEngine.Networking.NetworkHash128.i9 |
The documentation for this struct was generated from the following file:


Fast, reliable, accurate
Whether it is looking for a specific item in a review, to a specific topic in a school lecture, to a specific part in your favorite podcast, YouSearch promises to find exactly what you are looking for in any YouTube video.
The speed, reliability, and accuracy of YouSearch relies entirely on AWS. YouSearch initially pulls your YouTube video into a secure Amazon S3 Bucket for analysis. It then proceeds to utilize cutting-edge speech recognition and natural language processing techniques through Amazon Transcribe for the transcription process of the video and Amazon Comprehend for sentiment analysis.


OpenPathology is our project exploring and feeding back to clinicians on their test requesting rates.
Having established that patient counts are subject to some inaccuracy in existing analyses (see our previous blog), it’s important to sense check the accuracy of our own list size data.
Because two members of our OpenPathology team are also clinicians in North Devon, we have the opportunity to compare our data with known changes in practice.
Since about 2014, there has been a sustained and collaborative approach to improving the use of testing in primary care in North Devon. This has led to overall primary care testing rates in North Devon falling by 14% for full blood count testing and 22% for liver function tests, but without a reduction in the number of tests showing possible significant pathology.
The impact on the volumes of liver profiles requested by primary care can be seen in our OpenPathology data. Cornwall and North Devon had similar requesting rates in 2014, which have since diverged significantly:
Conclusions
This finding supports the notion that different areas are likely to have generally similar requesting rates for many analytes, but that these can be modified by specific interventions, and increases confidence that our list size data is likely to be correct.
It also shows the strength of the DataLab approach: clinicians, academics and software engineers working closely together, across disciplines and different parts of the NHS, to find new approaches and validate existing ones.
What next?
We would like to continue to validate this approach against known changes in clinical practice. In particular, we would like to find areas that have deliberately targeted the renal profile for demand management, or perhaps who have removed the potassium from the standard profile (as we know has occurred in some areas due to concerns about specimen stability). When we have data from more laboratories it will be interesting to explore these issues in more detail. If you are in a position to help us get data from more labs, please get in touch.


Central American offered asylum in Guatemala opts for home
by The Associated PressCOLON, Honduras — The first Central American asylum seeker sent to Guatemala under that country’s “safe third country” agreement with the U.S. has opted to instead return to his home in Honduras.
A tearful Erwin José Ardón Montoya arrived Saturday at his parent’s small adobe house in the village of Colón in the poverty- and drought-stricken municipality of Trujillo. He’d refused an offer of asylum in Guatemala.
Twenty-three-year-old Ardón Montoya said he hopes to perhaps set out again next year for the U.S., where his daughter was born seven months ago.
He was detained by the Border Patrol in El Paso, Texas, and sought asylum in the U.S. But the Trump administration deal with Guatemala led to him being sent there because he’d passed through the country en route to the U.S.
The Associated Press


This chapter explains what Websocket is and why it is a vital component of soft realtime Web applications.
Websocket is an extension to HTTP that emulates plain TCP connections between the client, typically a Web browser, and the server. It uses the HTTP Upgrade mechanism to establish the connection.
Websocket connections are asynchronous, unlike HTTP. This means that not only can the client send frames to the server at any time, but the server can also send frames to the client without the client initiating anything other than the Websocket connection itself. This allows the server to push data to the client directly.
Websocket is an IETF standard. Cowboy supports the standard and all drafts that were previously implemented by browsers, excluding the initial flawed draft sometimes known as "version 0".
Cowboy implements Websocket as a protocol upgrade. Once the upgrade is performed from the init/3
callback, Cowboy switches to Websocket. Please consult the next chapter for more information on initiating and handling Websocket connections.
The implementation of Websocket in Cowboy is validated using the Autobahn test suite, which is an extensive suite of tests covering all aspects of the protocol. Cowboy passes the suite with 100% success, including all optional tests.
Cowboy's Websocket implementation also includes the x-webkit-deflate-frame compression draft which is being used by some browsers to reduce the size of data being transmitted. Cowboy will automatically use compression as long as the compress
protocol option is set when starting the listener.


Already have an Intuit account?
I forgot my User ID or Password
Sign In
Mint
Quick Books
TurboTax
Create an Intuit account
One account for everything Intuit, including Mint.
Learn more
Email Adress
Phone (recommended)
Password
By clicking Create account, you agree to our
Terms
and have read and acknowledge our
Privacy Statement
.
Invisible reCAPTCHA by Google
Privacy Policy
and
Terms of Use
.


--- layout: post title: Slides from October meetup alias: /slides-from-october-meetup published: true ---
Max has published the slides from his responsive design talk last night.
[[posterous-content:CqaFaxjFHxCajsznFFrf]]
Frank's session was far too interactive to be captured as slides, so if you weren't there I'm afraid you missed out!


Your average guess is not better then your first guess!
| Times you tried this: |
|
| Times the average guess has been more accurate: |
|


Kettlebel Safety 101:
"It is your fault"
by Pavel Tstsuline in Enter The Kettlebell
-
Before starting training check with the doctor first, an orthopedist and a cardiologist. Kettlebell training can be exceptionally intense.
-
Always be aware of your surroundings. Train on a flat surface on which you can drop the kettlebell without worrying about it. Make sure, your line of fire is clear. If your kettlebell slips out of your hand, in the worst case scenario, it does not hit anybody or breaks something. Always be aware where the sun is. Be aware!
-
Wear flat sole shoes (no sneakers with cushion) or go barefoot. Recommended shoes: converse, chuck taylors, wrestling shoes, etc.
-
Never contest for space with the kettlebell. If the kettlebell wants to fall, get out of the way, do not fight it, let it go. Always remember: quick feet are happy feet!
-
Practice all safety measures at all times, even with very light kettlebell. Always pose the question for yourself: would I be willing to do this with a 48kg kettlebell? If the answer is no, then don’t do that. Mentally stay with the set until you release the kettlebell. At the last rep lower the kettlebell as you plan to do another rep, then set the kettlebell down. Only then you may relax.
-
Keep moving once your heart rate is high. When you've done a really hard set of swings or snaches do not just collapse to the ground, but keep moving! Walk, jug, shadowbox, it is going to make it easier on your heart.
-
Build up the training load gradually using common sense and listen to your body. Do not follow a workout blindly if you are just learning the movement or you are not strong enough yet. While you are at it, practice other exercises to gain strength and endurance. You MUST listen to your body!
-
Instruction can’t cover all contingencies. There is no substitute for good judgement. If you do not have good judgement, you should stay with the fitness machines.


{% extends "layout.html" %} {% block content %}
After submitting your application, find it in your list of submitted applications and click on the blue eye icon under "actions".
Copy the address/URL of your application. Apply in game on your main character, pasting the application address/URL into the in game application.
Wait for a recruiter to review your application and accept you.


JavaScript is disabled on your browser.
Skip navigation links
Overview
Package
Class
Tree
Deprecated
Index
Help
Prev Letter
Next Letter
Frames
No Frames
All Classes
A
B
C
D
E
F
G
H
I
J
M
N
O
P
R
S
T
U
G
getAccessToken()
- Method in class com.base.Auth.
AccessToken
getAccessToken()
- Method in class com.base.
BaseClient
getAccessToken()
- Method in class com.base.Http.Request.
Request
getApiUrl()
- Method in class com.base.
BaseClient
getBody()
- Method in class com.base.Http.Request.
JSONRequestBody
getBody()
- Method in class com.base.Http.Request.
Request
Get Request Body.
getBody()
- Method in interface com.base.Http.Request.
RequestBody
getBody()
- Method in class com.base.Http.Response.
Response
getClient()
- Method in class com.base.
Base
getClientId()
- Method in class com.base.
BaseClient
getClientSecret()
- Method in class com.base.
BaseClient
getCollection_name()
- Method in class com.base.Models.
Media
getContentType()
- Method in class com.base.Http.Request.
Request
getCreated_at()
- Method in class com.base.Models.
BaseModel
getCurrentUser()
- Method in class com.base.Services.
UserService
Get Currently Logged in User.
getCustom_properties()
- Method in class com.base.Models.
Media
getData()
- Method in class com.base.Models.
ResponseModel
getEmail()
- Method in class com.base.Models.
User
getEndpoint()
- Method in class com.base.Http.Request.
Request
Get Request Endpoint.
getErrorBag()
- Method in exception com.base.Exceptions.Http.
InputError
getErrors()
- Method in class com.base.Http.Response.
ErrorBag
getExpiredIn()
- Method in class com.base.Auth.
AccessToken
getFile_name()
- Method in class com.base.Models.
Media
getFiles()
- Method in class com.base.Http.Request.
Request
getHeaders()
- Method in class com.base.
BaseClient
getHeaders()
- Method in class com.base.Http.Request.
Request
Get Request Headers.
getHeaders()
- Method in class com.base.Http.Response.
Response
getHttpClient()
- Method in class com.base.
BaseClient
getId()
- Method in class com.base.Models.
BaseModel
getManipulations()
- Method in class com.base.Models.
Media
getMessage()
- Method in class com.base.Http.Response.
ErrorBag
getMethod()
- Method in class com.base.Http.Request.
Request
Get Request Method.
getMime_type()
- Method in class com.base.Models.
Media
getName()
- Method in class com.base.Models.
Media
getName()
- Method in class com.base.Models.
User
getParameters()
- Method in class com.base.Http.Request.
Request
Get Request Parameters.
getRefreshToken()
- Method in class com.base.Auth.
AccessToken
getRequest()
- Method in class com.base.Http.Response.
Response
getResponse()
- Method in exception com.base.Exceptions.
BaseHttpException
getResponseHandler()
- Method in class com.base.
BaseClient
getSize()
- Method in class com.base.Models.
Media
getStatusCode()
- Method in class com.base.Http.Response.
Response
getUpdated_at()
- Method in class com.base.Models.
BaseModel
getUrl()
- Method in class com.base.Http.Request.
Request
getUrl()
- Method in class com.base.Models.
Media
getUrl(String)
- Method in class com.base.Models.
Media
getUserAccessToken(String, String)
- Method in class com.base.
Base
Get User Access Token (Login).
getUserAccessToken()
- Static method in class com.base.
Main
A
B
C
D
E
F
G
H
I
J
M
N
O
P
R
S
T
U
Skip navigation links
Overview
Package
Class
Tree
Deprecated
Index
Help
Prev Letter
Next Letter
Frames
No Frames
All Classes


--- # You don't need to edit this file, it's empty on purpose. # Edit theme's home layout instead if you wanna make some changes # See: https://jekyllrb.com/docs/themes/#overriding-theme-defaults layout: default title: Charles Brown-Roberts Developer Projects ---


The steering wheel restoring that we offer includes:
- Cleaning the steering wheel with a proper leather detergent
- If needed or on demand the steering wheel could be repainted with special paint
- Varnishing the steering wheel
- We keep the authentic color, but on demand of the client it could be changed!
We guarantee our services and the quality of our work!
Back to services