|
LE DEUXIEME SEXE (The Second Sex)
“....Then from woman’s point of view I shall describe the world in which women must live;
and thus we shall be able to envisage the difficulties in their way as, endeavouring to make their escape from the sphere hitherto assigned them,
they aspire to full membership in the human race.”
Simone de Beauvoir
This series of 16 photographs is a tribute to the book “Le deuxième sexe” written in 1949 by Frenchwoman Simone de Beauvoir (1908 - 1986),
a tremendously important work for the women’s liberation movement since it analyses the different reasons for women’s historical inferiority in society.
The images in the series represent different women as contemporary paradigms of the inferior position women have endured throughout mankind’s history.
Simone de Beauvoir analyses the historical definition of the man-woman couple as the basic unit, wherein man is One and woman is the Other.
She maintains that it is men who have run the world, while women were forced to take on the role of devoting themselves entirely to marriage and children,
at the risk of limiting their freedom and denying their human rights.
Society, family, religion and the law have historically reasserted woman’s inferiority to man.
Whereas the One is virile, energy, light, combat, power and intelligence, the Other is passivity, disarray, contradiction, opaqueness and the source of evils.
It is Eve who causes man’s perdition, and, with him, that of all humanity.
It is the curious Pandora who, through her disobedience, unleashes Earth’s miseries. Pandora is born after man, unfinished, secondary and inferior.
“A woman isn’t born as such; she becomes one” writes de Beauvoir, in reference to the different roles society imposes depending on one’s gender.
In their personal tragedies, the heroines of the series The Second Sex represent that vulnerability which remains untranscended well into the 20th century.
Many women, despite their daily struggle against mediocrity and having to face social atavisms,
have been unable to achieve the corresponding emancipation and personal recognition. Others are not even the Other;
rather, they are “nothing” because it was their unfortunate lot to be born into profoundly misogynistic societies.
Our selection, neither exhaustive nor exclusive, presents different situations related to the feminine condition as represented by 16 women:
Aicha
Like Mohammed’s youthful wife, Aicha married very young; and total (though unrequited) devotion to her spouse was demanded of her.
In many families today, women still risk being disowned and repudiated by society should they engage in “conduct unbecoming”.
Elienor
Inspired by the great Elienor of Aquitaine, she represents the cultivated woman who,
despite her enormous intellectual capacity, is unable to rise in social circles.
Angela
Like Angela of Foligno —who in her day relinquished all her possessions for the good of her fellow men, receiving nothing in return—
this woman disregards her own happiness.
Aspasia
A high-ranking courtesan and procurer of enormous political influence, this poet of ancient Greece exploited her womanhood for the sake of social advancement.
She was charged and prosecuted by a jury of 1500 men and was not permitted to speak in her name.
Atalanta
Heroine from Greek mythology. Abandoned at birth by her father, who only wanted sons, she developed boundless physical agility and intelligence,
defeating men in both footraces and hunting, and rebelling against the patriarchal frameworks.
Carmen
She is the gypsy tobacco seller of Georges Bizet’s opera, murdered by a jealous man.
Fatima
The virtuous and venerated daughter of the prophet Mohammed, who called her “the noblest woman in Paradise”.
Today, she lives on the street and has lost society’s respect and recognition.
Inana
Goddess of light and darkness in Mesopotamian mythology, she descends into Hell to save her sister and has no choice but to remain there.
Stripped of garments, jewels, crowns, sceptre, she finds herself alone, confronting ghosts and fears.
We can find today’s Inana in the hell of poverty, her feminine condition making it even more difficult to find a way out.
Jezabel
This queen of Israel mentioned in the Old Testament is accused of adoring her own god and punished for it.
She represents the woman who by herself imposes her convictions in a hostile society.
Lucrecia
A figure belonging to the history of ancient Rome, portrayed countless times in art,
she is the woman who, ill-treated as regards her person and character, self-destructs.

She represents the difficult social ascent of the woman who emigrates to wealthy societies.
Pandora
According to Greek mythology, this woman is accused of releasing all the evils of mankind (illness, insanity, vice, passion, sadness, poverty, crime, etc.).
She is an example of the myth of a patriarchal society imposed upon a formerly matriarchal society.
Raquel
According to the Hebrew Bible, this woman bemoans her banished sons in the face of universal indifference.
In Judaism, Raquel weeps for an end to the exile and suffering of her descendants.
Rita
Saint Rita of Cassia, who lived in the 14th century, was the patron saint of lost causes.
She is the woman who today continues to personally endure macho violence.
Rosalia
As the patron saint of Palermo, Sicily, she represents the woman deprived of her freedom and condemned to live in eternal captivity.
|


First comes the sinking feeling, subtle, it grows stronger, like my body is oozing into lead, dragging my heart down to the floor. It's a slow rhythmic movement down, like a nail banged ever deeper inward by the potent chemical hammer I've got swinging inside of me.  My mind is falling, a downward spiral into a cave, splashing into the water, bobbing around in the murky mist. Into the fog. Everything is different yet everything is the same. Looking around the room I can see all the furniture where it should be, just sitting there, everything is fine. But things are off, the borders move around, twisting between realities. A swarm of colored dots, like bats fill my vision before getting lost in the light of clarity shining down at me from the caves opening. I enjoy it now, I know it won't be long before I'm swept away, before I'm diving downward into the cold lonely depths of insanity.
The Diphenhydramine is hitting.
I counted the pills over and over at 10:00, deciding how much to do, anxiety ever growing. Finally I got the strength to down them, swallowing the handful with a strained gulp. No going back now.
It's been almost an hour. I'm feeling normal, I'm feeling fine. Then there is a large buzz building in the back of my brain, like a fever sneaking in on me. I'm turning into lead, I'm sinking. Boom, the fear hits. I hear a crack, my mind is in shock for a second, reeling a thousand miles per hour backwards. Iím back, fine again, but I know, itís starting.
Iíve dove straight into insanity, Iím in another reality know, slipping in between worlds. First sign is the change. I hear spare change falling down around me like rain. Going for a bit, then stopping. Every time this happens I get a little jolt of fear. Iím used to this though, the change comes raining down every time the dryl is involved. Iím enjoying this, purple blobs and dots dance on the walls. Bouts of double vision come and go. I keep hearing voices, I canít make out the words though, Iím still to rooted in the real, clarity will come though.
Soon Iíve passed this, Iím now deep within the sea of lunacy, my mind is spinning. Iím in my kitchen drinking some water, I got to get an ice tea from the kitchen, BAM, Iím in my room, no ice tea, I go downstairs, get the same ice tea, the can is closed, I look down again, itís open. Itís like Iím slipping in and out of time, the order is all wrong. The dementia is hitting now, Iím no longer feeling cold, I get flashes of heat, I feel sick dizzy. My mind is fried, one second Iím in my basement hearing change fall, next Iím talking to my 10th grade English teacher, weíre discussing my trip and what I can learn while out of my home world. I turn around, heís gone, I realize whatís going on, I realize the hallucination, or was it?
I hear the door bell at one point, I donít dare go down though, I eventually end up at the door, standing on the step waiting for 10 minutes, but then I realize they must have left 30 minutes ago, I wonder if I really heard my doorbell? I ring it to get the sound in my ears, was that me who rung it, am I going back through time, is the oder of my senses and memory all messed up?
Itís getting hotter and hotter. The world is turning into straight shapes, black and white, dark purple splotches over everything. Iím in a hot machine world, itís twisting around me, moving me from place to place, Iím growing sicker and sicker.
Iíve lost free will, Iím lead by fate, like a fly stuck in a spiders web Iím flung around my fates weavings. I move from place to place and back again, huge whole fill my memory at every turn. It must be around 2 or 3 now.
I decide I need to take a shower, I get in the hot water and zone out. I no longer feel so hot when I get out. Iím calm. I go to lie down in my room. Itís pitch black. Lightning sparks across my closed eyelids, a fierce internal storm and Iím stuck in the calm eye. I feel totally relaxed, my muscles loosen. Shapes dance across my mind back and forth. Iím disconnected from the world. Then I see it, Iíve seen it on Diphenhydramine before, the eye, the eye of insanity. A bright amorphous blob bobbing in my vision, bright reddish purple swirling around, and iris with a void in the center that draws me forward. Iím staring into the eyes of insanity, I realize this in the back of my mind, Iíve called it this before in writing and thus remember it as such, but only subconsciously in a vague sense. Iím in total trance.
Iím leaving the world. I can feel myself drifting downward, slowly spiraling back into myself, the eyes gaze and mine interlocked. This hallucination keeps for a long while as I feel myself falling further down. I can feel my pulse, feel every organ moving, I can hear every breath I have no control over. Then nothing, itís like a 3rd plateau DEX trip, Iím hypnotized, without sense, almost without ego. Then, unconsciousness.
I must have come back up from that place in my sleep. I awake deep in a chemical fog.   I get up and drink some water then back to sleep, this process is repeated many times. Finally I drag myself back up. Iíve returned to my world, to my origin.   Have I twisted everything or has everything twisted to me. I canít tell. Iíve traveled outside and came back through into a haze.
 Its an interesting experience, diving into fates hands, giving up control and staring into lunacy for a while, letting myself out the door, when I come back everything is the same, but Iím not, I have the same views as before but also new ones I gained while lost. It wasnít introspective like the 3rd, more a loss of all grounding, which, having experienced it has let me think and believe in whole new ways.
A strange trip but one worth remembering
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.


Every year I go up to Vermont and host a multi day party. My brother and I own a small cabin in the woods and we pack it full of people. It’s like a little ski shack, but we shove people in it like crazy. There are 5 very small bedrooms in the house. We’ve had as many as 34 people stay the night. It’s packed!  I may end up renting a summer camp before/after camp is in session and let people from the platform come for a week and hang out like it was steem summer camp :)
We’ve been hosting this party for over 25 years. And I’m blessed to have friends that have been coming for more than a decade some of them I’ve known for 30 years. Most of them I’ve known for 20 years or more. I have a very blessed life that I’m grateful for on the daily.
Now, it takes some qualities to be handle a 15-30 person party in a house not really designed for more than 10 at a time. I just want to pull a few of those things together and talk about some characteristics of my best friends for 30 years.
Current/Former outdoors people
Most of us met at outdoor summer camps. I’ve personally hiked over 400 miles on the Appalachian trail. Some of these people have done most of those miles with me. If you can handle the stress of carrying a 40-80lbs pack, filled with communal stuff, have to take turns at chores, pissing and shitting in the woods and outhouses, and living without electronics for a while then you’re my kind of people. These folks have inner strength, a lot of character, physical strength, and a tolerance for living in less than luxurious settings (which this party requires).
Professional Nerds
Look at the room I see an architect, a computer programmer, an accountant, a pharma project manager, and me. Often we have some lawyers, teachers, and doctors up here too. We’re nerds. I roll with nerds. Literally, I roll dice with nerds as we play pathfinder, splendor, catan, and a million other euro style games. One of the foundations of this place is a willingness to hang out and play games and have that be a fun weekend.
Work Ethic
The house is heated by wood. I had to go out this morning in sub zero temperatures to take wood from the primary stack, bring it inside, and stoke the fire. I would have done it alone. I didn’t ask anyone to go, and within 5 minutes of being outside two other dudes were there to help me stack.   They have a sense of pitching in. Sure it makes us all warm, but they could have let me do it all, but my peeps don’t mind contributing.
Warmth
I think after all the years I’ve lived I’ve finally settled on the most important feature of a person that I look for is warmth. You’re allowed good days and bad days. You’re allowed to be happy or sad. The best measurement of your baseline is your level of warmth. Not temperature so much as genuine kindness and caring towards other people. Looks will fade. Brains will slow. But your heart will keep being kind towards others if that’s what you cultivated. My friends will pickup the phone to check in if you’re sick. They’ll root for you when there is success they themselves aren’t currently experiencing. They look out for one another.
I’m blessed
Most of the world doesn’t have it as good as my family does. That’s part of why I think it’s so important that I spend my time fighting for change. I’m looking to spread Peace, Abundance, and Liberty throughout the world. I’m blessed by a lovely wife, amazing kids, and fantastic friends. Hopefully your friends support you, love you, and care for you and it’s reciprocal.
This page is synchronized from the post: ‘Four qualities of my dearest friends (almost 10k followers!)’


Advertisements
The teenager, named Jiang Hua, was playing with the magnetic ‘Buckyballs’ toy on the night of November 12 when he decided to start putting the little metal objects up his urethra.

Advertisements
When he failed to do so, he came up with the idea of inserting even more balls, in an attempt to draw them all out together using their magnetic force. He spent an hour putting this plan into action but unfortunately it only resulted in the balls being pushed further and further up into his body, Chutian Urban Newspaper reports, as per the MailOnline.

The following day, when he was at school, Jiang found he was bleeding down below. The bleeding continued throughout the day so the concerned teen decided to inform his grandfather, who he lived with, about what he’d done.
The grandfather was understandably shocked at the news and he later described his grandson’s underwear as being covered in blood.
Advertisements
Jiang was taken to children’s hospital, where doctors described him as pale, dizzy and in shock. It was discovered the metal balls had clumped together into two strings inside Jiang, resulting in life-threatening haemorrhaging.
On Wednesday, November 13, the teen underwent an operation performed by hospital director and urologist Dr Wang Jun. He managed to successfully remove all 53 magnets, in turn saving Jiang from ‘critical condition’.

Though the balls had been inside him for a worryingly long time, the young boy only went to hospital when he started experiencing abdominal pains.
After being pulled aside by doctors, he admitted he had forced Buckyballs into his urethra while ‘exploring his anatomy’.

You wouldn’t think the toy would need a disclaimer to warn against such usage, but apparently it really does.
Emily Brown first began delivering important news stories aged just 13, when she launched her career with a paper round. She graduated with a BA Hons in English Language in the Media from Lancaster University, and went on to become a freelance writer and blogger. Emily contributed to The Sunday Times Travel Magazine and Student Problems before becoming a journalist at UNILAD, where she works on breaking news as well as longer form features.


ODE(1) GNU Plotting Utilities ODE(1) NAME ode - numerical solution of ordinary differential equations SYNOPSIS ode [ options ] [ file ] DESCRIPTION ode is a tool that solves, by numerical integration, the initial value problem for a specified system of first-order ordinary differential equa‐ tions. Three distinct numerical integration schemes are available: Runge-Kutta-Fehlberg (the default), Adams-Moulton, and Euler. The Adams-Moulton and Runge-Kutta schemes are available with adaptive step size. The operation of ode is specified by a program, written in its input lan‐ guage. The program is simply a list of expressions for the derivatives of the variables to be integrated, together with some control statements. Some examples are given in the EXAMPLES section. ode reads the program from the specified file, or from standard input if no file name is given. If reading from standard input, ode will stop reading and exit when it sees a single period on a line by itself. At each time step, the values of variables specified in the program are written to standard output. So a table of values will be produced, with each column showing the evolution of a variable. If there are only two columns, the output can be piped to graph(1) or a similar plotting pro‐ gram. OPTIONS Input Options -f file --input-file file Read input from file before reading from standard input. This option makes it possible to work interactively, after reading a program fragment that defines the system of differential equa‐ tions. Output Options -p prec --precision prec When printing numerical results, use prec significant digits (the default is 6). If this option is given, the print format will be scientific notation. -t --title Print a title line at the head of the output, naming the variables in each column. If this option is given, the print format will be scientific notation. Integration Scheme Options The following options specify the numerical integration scheme. Only one of the three basic options -R, -A, -E may be specified. The default is -R (Runge-Kutta-Fehlberg). -R [stepsize] --runge-kutta [stepsize] Use a fifth-order Runge-Kutta-Fehlberg algorithm, with an adaptive stepsize unless a constant stepsize is specified. When a constant stepsize is specified and no error analysis is requested, then a classical fourth-order Runge-Kutta scheme is used. -A [stepsize] --adams-moulton [stepsize] Use a fourth-order Adams-Moulton predictor-corrector scheme, with an adaptive stepsize unless a constant stepsize, stepsize, is specified. The Runge-Kutta-Fehlberg algorithm is used to get past `bad' points (if any). -E [stepsize] --euler [stepsize] Use a `quick and dirty' Euler scheme, with a constant stepsize. The default value of stepsize is 0.1. Not recommended for serious applications. The error bound options -r and -e (see below) may not be used if -E is specified. -h hmin [hmax] --step-size-bound hmin [hmax] Use a lower bound hmin on the stepsize. The numerical scheme will not let the stepsize go below hmin. The default is to allow the stepsize to shrink to the machine limit, i.e., the minimum nonzero double-precision floating point number. The optional argument hmax, if included, specifies a maximum value for the stepsize. It is useful in preventing the numerical rou‐ tine from skipping quickly over an interesting region. Error Bound Options -r rmax [rmin] --relative-error-bound rmax [rmin] The -r option sets an upper bound on the relative single-step error. If the -r option is used, the relative single-step error in any dependent variable will never exceed rmax (the default for which is 10^-9). If this should occur, the solution will be aban‐ doned and an error message will be printed. If the stepsize is not constant, the stepsize will be decreased `adaptively', so that the upper bound on the single-step error is not violated. Thus, choosing a smaller upper bound on the single-step error will cause smaller stepsizes to be chosen. A lower bound rmin may optionally be specified, to suggest when the stepsize should be increased (the default for rmin is rmax/1000). -e emax [emin] --absolute-error-bound emax [emin] Similar to -r, but bounds the absolute rather than the relative single-step error. -s --suppress-error-bound Suppress the ceiling on single-step error, allowing ode to con‐ tinue even if this ceiling is exceeded. This may result in large numerical errors. Informational Options --help Print a list of command-line options, and exit. --version Print the version number of ode and the plotting utilities pack‐ age, and exit. DIAGNOSTICS Mostly self-explanatory. The biggest exception is `syntax error', mean‐ ing there is a grammatical error. Language error messages are of the form ode: nnn: message... where `nnn' is the number of the input line containing the error. If the -f option is used, the phrase "(file)" follows the `nnn' for errors encountered inside the file. Subsequently, when ode begins reading the standard input, line numbers start over from 1. No effort is made to recover successfully from syntactic errors in the input. However, there is a meager effort to resynchronize so more than one error can be found in one scan. Run-time errors elicit a message describing the problem, and the solution is abandoned. EXAMPLES The program y' = y y = 1 print t, y step 0, 1 solves an initial value problem whose solution is y=e^t. When ode runs this program, it will write two columns of numbers to standard output. Each line will show the value of the independent variable t, and the variable y, as t is stepped from 0 to 1. A more sophisticated example would be sine' = cosine cosine' = -sine sine = 0 cosine = 1 print t, sine step 0, 2*PI This program solves an initial value problem for a system of two differ‐ ential equations. The initial value problem turns out to define the sine and cosine functions. The program steps the system over a full period. AUTHORS ode was written by Nicholas B. Tufillaro (nbt@reed.edu), and slightly enhanced by Robert S. Maier<EMAIL_ADDRESS>to merge it into the GNU plotting utilities. SEE ALSO "The GNU Plotting Utilities Manual". BUGS Email bug reports to<EMAIL_ADDRESS>FSF Dec 1998 ODE(1)


Info
RSVP
In Loving Memory
Tibor Laszlo Cseley
27 February 1930 - 11 February 2015
RSVP
Full Name
First Name
Last Name
E-mail
Are you attending?
Yes
No
Number of People
Submit
Should be Empty:


--- layout: post title: NHibernate and OpenRasta frenzy in Aarhus, Denmark date: '2009-08-11T17:00:00.001+01:00' tags: [nhibernate, openrasta, training] modified_time: '2009-08-11T17:00:04.097+01:00' blogger_id: tag:blogger.com,1999:blog-4015568221071268916.post-8566001046446409712 comments: true blogger_orig_url: http://serialseb.blogspot.com/2009/08/nhibernate-and-openrasta-frenzy-in.html ---
On a very positive note, I’ll be delivering Skillsmatter’s NHibernate course in Aarhus, Denmark, from the 26th to the 28th of August.
I’m also discussing with some guys to get an OpenRasta presentation there so you can hear what the fuss is all about.
And I’ll take the Saturday to visit Copenhagen, as it would be a shame not to. If some people are available Saturday we can meet for a beer and a chat.
First time in Denmark, I’m quite excited!


typedef struct { word SD4RTT_numTriggers; StandardDialogResponseTriggerEntry SD4RTT_trigger1; StandardDialogResponseTriggerEntry SD4RTT_trigger2; StandardDialogResponseTriggerEntry SD4RTT_trigger3; StandardDialogResponseTriggerEntry SD4RTT_trigger4; } StandardDialog4ResponseTriggerTable;
typedef enum /* word */ { SP_NOT_STANDARD_PATH=0, SP_TOP=1, SP_APPLICATION=3, SP_DOCUMENT=5, SP_SYSTEM=7, SP_PRIVATE_DATA=9, SP_STATE=11, SP_FONT=13, SP_SPOOL=15, SP_SYS_APPLICATION=17, SP_PUBLIC_DATA=19, SP_MOUSE_DRIVERS=21, SP_PRINTER_DRIVERS=23, SP_FILE_SYSTEM_DRIVERS=25, SP_VIDEO_DRIVERS=27, SP_SWAP_DRIVERS=29, SP_KEYBOARD_DRIVERS=31, SP_FONT_DRIVERS=33, SP_IMPORT_EXPORT_DRIVERS=35, SP_TASK_SWITCH_DRIVERS=37, SP_HELP_FILES=39, SP_TEMPLATE=41, SP_POWER_DRIVERS=43, SP_DOS_ROOM=45, SP_HWR=47, SP_WASTE_BASKET=49, SP_BACKUP=51, SP_PAGER_DRIVERS=53 SP_DUMMY=256 } StandardPath;
Most routines which are passed disk handles can also be passed members of the
StandardPath
enumerated type. Standard paths let applications access files in a disk-independent manner. Standard paths are usually arranged in a certain hierarchy; for example, the STATE directory usually belongs to the PRIVDATA directory. However, this is entirely at the user's discretion; applications may not make any assumption about how the standard paths are arranged.
typedef enum{ STREAM_WOULD_BLOCK, STREAM_CLOSING, STREAM_CANNOT_ALLOC, STREAM_BUFFER_TOO_LARGE, STREAM_CLOSED, STREAM_SHORT_READ_WRITE } StreamError;
typedef enum { STREAM_OPEN_NO_BLOCK = 0x01, STREAM_OPEN_TIMEOUT = 0x02 } StreamOpenFlags
typedef enum { STREAM_ROLES_WRITER = 0, STREAM_ROLES_READER = -1, STREAM_ROLES_BOTH = -2 } StreamRoles;
typedef struct { VMFileHandle SCD_vmFile; word SCD_vmBlockOrMemHandle; ChunkHandle SCD_chunk; } StyleChunkDesc;


ProTipper
Bill Total:
How would you like to split the bill:
How was your service?
Outstanding - 30%
Good - 20%
Average - 15%
Below Average - 10%
Poor - 5%
Calculate!
Tip amount:
Total per person:


ERASER A film review by Lori Ann Chauvette Copyright 1996 Lori Ann Chauvette
Starring: Arnold Schwarzenneger Vanessa Williams James Caan Robert Pastorelli
What can I say? Arnold has done it again with his latest film, "Eraser".
He plays Witness Protection Program employee John Kruger, in charge of "erasing" people's identities in order to protect them. This time his charge is Lee Cullen (Williams), a woman who knows too much about the dirty dealings at a weapons corporation.
There's not really much more you can say about the plot. And I don't think anyone who goes to see Schwarzennegar films really cares. There was a director who once said to Roger Ebert that in order for a movie to be great, it has to have at least three good scenes and no bad scenes. And in Ebert's review, he said, "This movie has four good scenes and no bad scenes." And I would have to agree with him on that point.
Despite the probably many impossibilities in this film, such as the cannon-guns used by the bad guys, this movie kept my attention throughout. The one-liners (Arnold's trademark) were fast and funny, the action was the best of any Schwarzennegar film in history, and Pastorelli was great as the Mafioso- witness who was helped by Schwarzennegar in the beginning of the film, providing even more comic relief. If I wasn't cheering, I was laughing. And that's what an action movie should be.
Three and a half stars (out of a possible four)
-- Lori Ann Chauvette<EMAIL_ADDRESS>http://members.aol.com/scully3257/index.htm
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


You don't have javascript enabled
REFLEX.io
Copy url and give your friend to connect!
Typed Words
time
Leaderboard


Server Error
An unexpected error occurred. We have been notified, of this issue.
Please check again later.


--- layout: work title: Concerto 2 ---
2013-2016
Concerto is an open source digital signage platform for sharing multimedia advertisements within communities. In its most basic form, it's a way of posting and managing community advertisements on flat panel televisions and other screens.
MY ROLES
Interaction Design, Branding, UI Engineering, Visual Design
COMPANY
Self-Started
The first version of Concerto launched while I was still in college at RPI. I worked with a group of six other core team members—all engineers—and led the user experience design for the team. Designing Concerto 1.0 and its subsequent releases was a completely green-field endeavor—we defined the product requirements and mostly designed the software that we ourselves, as students, wanted to use to help publicize our clubs’ events on campus.
For 2.0, we had a much larger base of feedback at our disposal. The response to 1.0 was simply incredible. The source code was downloaded by people in over 70 countries and the Google Group we set up included legions of excited people. People would regularly send our team emails about how much they loved Concerto, especially how easy it was for them to set up and put into use within their own user communities.

Because plugins would be coming into the mix with Concerto 2, I wanted the organization of the administration interface to support groups of interrelated pages. I developed a simple one-tier grouping of menu tabs for the main menu that could also grow naturally as Concerto plugins add new pages to the application. The full menu is replaced by a much simpler presentation when no user is logged in.
Concept Development
In 1.0, content creation was done through one page with an inflexible set of horizontal tabs. With the promise of Concerto 2 plugins adding new types of content, I needed to come up with a more flexible design. I organized this area around the type of content and employed a tab group that could be expanded with plugins. Each content type can ask for different things from the content submitter.
One thing that became apparent from conducting user tests of the 1.0 UI was the need for a content preview to ensure the advertisement looked right before submission. I worked with other members of the team to design a simple live preview that would show the new ad before choosing to submit. This proved a bit tricky because we needed to stream data from the client browser and create a kind of temporary record of the media file before the full content record was actually created.
The user goal through this flow is to approve or deny advertisements added to Concerto by others within their organizations. I sought to embed the moderation process directly into the content browsing interface. If the current user has moderation privileges, they simply see contextual controls layered over the content in their view. This also made these interfaces easier for the team to build.
Concerto 1 used a list interface to manage screen content type subscriptions. For Concerto 2, I developed a simple interface allowing the user to see and manage the actual screen regions and subscriptions in a visual way.
Concerto 2.0 was finally released to the world in June 2014. Since then, the product has been downloaded many thousands of times and has expanded the reach of the project to a much large audience. Try the product and download it at concerto-signage.org!


Ukay-ukay is a second-hand store that sells cast-off apparel, bags, shoes, fashion accessories and other items not normally found in the regular department stores. (Although some popular brands often have their hand-me-down counterparts at the ukay-ukay.) It is the Pinoy flea market of dry goods, mostly clothes and other fashion items.


Dark Mode
option did not switch on or off Dark ModeYou can use Material UI and The Doki-Doki Theme side-by-side now!
Installing the Material UI and the Doki-Doki Theme will now work independently of each other! ᕙ(⇀‸↼‶)ᕗ
The 2018.3 builds of the JetBrain's IDEs are now better supported!
All known progress indicators now conform more to the icon update
Sometimes, when you're writing a poem - or a story - your brain gets fixated on a specific point. If you try so hard to make it perfect, then you'll never make any progress. Just force yourself to get something down on the paper, and tidy it up later!  So just move your hand, and go with the flow!
Toggle Dark Mode
to switch between light and dark!Swap Chibi
(for less yandere club members).Toggle Joyfulness
became Swap Chibi


In this tutorial you will learn how to implement a simple network protocol using libdill.
The source code for individual steps of this tutorial can be found in tutorial/protocol
subdirectory.
Handles are libdill's equivalent of file descriptors. A socket implementing our protocol will be pointed to by a handle. Therefore, we have to learn how to create custom handle types.
Standard include file for libdill is libdill.h
. In this case, however, we will include libdillimpl.h
which defines all the functions libdill.h
does but also adds some extra stuff that can be used to implement different plugins to libdill, such as new handle types or new socket types:
#include <libdillimpl.h>
To make it clear what API we are trying to implement, let's start with a simple test program. We'll call our protocol quux
and at this point we will just open and close the handle:
int main(void) {
int h = quux_open();
assert(h >= 0);
int rc = hclose(h);
assert(rc == 0);
return 0;
}
To start with the implementation we need a structure to hold data for the handle. At the moment it will contain only handle's virtual function table:
struct quux {
struct hvfs hvfs;
};
Let's add forward declarations for functions that will be filled into the virtual function table. We'll learn what each of them is good for shortly:
static void *quux_hquery(struct hvfs *hvfs, const void *id);
static void quux_hclose(struct hvfs *hvfs);
The quux_open
function itself won't do much except for allocating the object, filling in the table of virtual functions and registering it with libdill runtime:
int quux_open(void) {
int err;
struct quux *self = malloc(sizeof(struct quux));
if(!self) {err = ENOMEM; goto error1;}
self->hvfs.query = quux_hquery;
self->hvfs.close = quux_hclose;
int h = hmake(&self->hvfs);
if(h < 0) {err = errno; goto error2;}
return h;
error2:
free(self);
error1:
errno = err;
return -1;
}
Function hmake()
does the trick. You pass it a virtual function table and it returns a handle. When the standard function like hclose()
is called on the handle libdill will forward the call to the corresponding virtual function, in this particular case to quux_hclose()
. The interesting part is that the first argument to the virtual function is no longer the handle but rather pointer to the virtual function table. And given that virtual function table is a member of struct quux
it's easy to convert it to the pointer to the quux object itself.
quux_hclose()
virtual function will deallocate the quux object:
static void quux_hclose(struct hvfs *hvfs) {
struct quux *self = (struct quux*)hvfs;
free(self);
}
At the moment we can just return ENOTSUP
from the other two virtual functions.
Compile the file and run it to test whether it works as expected:
$ gcc -o step1 step1.c -ldill
Consider a UDP socket. It is actually multiple things. It's a handle and as such it exposes functions like hclose()
. It's a message socket and as such it exposes functions like msend()
and mrecv()
. It's also a UDP socket per se and as such it exposes functions like udp_send()
or udp_recv()
.
libdill provides an extremely generic mechanism to address this multi-faceted nature of handles. In fact, the mechanism is so generic that it's almost silly. There's a hquery()
function which takes ID as an argument and returns a void pointer. No assumptions are made about the nature of the ID or nature of the returned pointer. Everything is completely opaque.
To see how that can be useful let's implement a new quux function.
First, we have to define an ID for quux
object type. Now, this may be a bit confusing, but the ID is actually a void pointer. The advantage of using a pointer as an ID is that if it was an integer you would have to worry about ID collisions, especially if you defined IDs in different libraries that were then linked together. With pointers there's no such problem. You can take a pointer to a global variable and it is guaranteed to be unique as two pieces of data can't live at the same memory location.
static const int quux_type_placeholder = 0;
static const void *quux_type = &quux_type_placeholder;
Second, let's implement hquery()
virtual function, empty implementation of which has been created in previous step of this tutorial:
static void *quux_hquery(struct hvfs *hvfs, const void *type) {
struct quux *self = (struct quux*)hvfs;
if(type == quux_type) return self;
errno = ENOTSUP;
return NULL;
}
To understand what this is good for think of it from user's perspective: You call hquery()
function and pass it a handle and the ID of quux handle type. The function will fail with ENOTSUP
if the handle is not a quux handle. It will return pointer to quux
structure if it is. You can use the returned pointer to perform useful work on the object.
But wait! Doesn't that break encapsulation? Anyone can call hquery()
function, get the pointer to raw quux object and mess with it in unforeseen ways.
But no. Note that quux_type
is defined as static. The ID is not available anywhere except in the file that implements quux handle. No external code will be able to get the raw object pointer. The encapsulation works as expected after all.
All that being said, we can finally implement our new user-facing function:
int quux_frobnicate(int h) {
struct quux *self = hquery(h, quux_type);
if(!self) return -1;
printf("Kilroy was here!\n");
return 0;
}
Modify the test to call the new function, compile it and run it:
int main(void) {
...
int rc = quux_frobnicate(h);
assert(rc == 0);
...
}
Let's turn the quux handle that we have implemented into quux network socket now.
We won't implement the entire network stack from scratch. The user will layer the quux socket on top of an existing bytestream protocol, such as TCP. The layering will be done via quux_attach()
and quux_detach()
functions.
In the test program we are going to layer quux protocol on top of ipc protocol (UNIX domain sockets):
coroutine void client(int s) {
int q = quux_attach(s);
assert(q >= 0);
/* Do something useful here! */
s = quux_detach(q);
assert(s >= 0);
int rc = hclose(s);
assert(rc == 0);
}
int main(void) {
int ss[2];
int rc = ipc_pair(ss);
assert(rc == 0);
go(client(ss[0]));
int q = quux_attach(ss[1]);
assert(q >= 0);
/* Do something useful here! */
int s = quux_detach(q);
assert(s >= 0);
rc = hclose(s);
assert(rc == 0);
return 0;
}
To implement it the socket first need to remember the handle of the underlying protocol so that it can use it when sending and receiving data:
struct quux {
...
int u;
};
To accomodate libdill's naming conventions for protocols running on top of other protocols, we have to rename quux_open()
to quux_attach()
. Attach function will accept a handle of the underlying bytestream protocol and create quux protocol on top of it:
int quux_attach(int u) {
int err;
struct quux *self = malloc(sizeof(struct quux));
if(!self) {err = ENOMEM; goto error1;}
self->hvfs.query = quux_hquery;
self->hvfs.close = quux_hclose;
self->hvfs.done = quux_hdone;
self->u = hown(u);
int h = hmake(&self->hvfs);
if(h < 0) {int err = errno; goto error2;}
return h;
error2:
free(self);
error1:
errno = err;
return -1;
}
Note gow hown
function is used to take ownership of the underlying socket. hown
will give it a new handle number, thus making the old handle number owned by the caller unusable.
We can reuse quux_frobnicate
and rename it to quux_detach
. It will terminate the quux protocol and return the handle of the underlying protocol:
int quux_detach(int h) {
struct quux *self = hquery(h, quux_type);
if(!self) return -1;
int u = self->u;
free(self);
return u;
}
libdill recognizes two kinds of network sockets: bytestream sockets and messages sockets. The main difference between the two is that the latter preserves the message boundaries while the former does not.
Let's say quux will be a message-based protocol. As such, it should expose functions like msend
and mrecv
to the user.
Do you remember the trick with adding new function to a handle? If not so, re-read step 2 of this tutorial. For adding message socket functions to quux we'll use the same mechanism except that instead of defining our own type ID we will use an existing one (msock_type
) defined by libdill. Passing msock_type
to hquery function will return pointer to a virtual function table of type msock_vfs
. The table is once again defined by libdill:
struct msock_vfs {
int (*msendl)(struct msock_vfs *vfs,
struct iolist *first, struct iolist *last, int64_t deadline);
ssize_t (*mrecvl)(struct msock_vfs *vfs,
struct iolist *first, struct iolist *last, int64_t deadline);
};
To implement the functions, we have to first add the virtual function table to quux socket object:
struct quux {
struct hvfs hvfs;
struct msock_vfs mvfs;
int u;
};
We'll need forward declarations for msock
functions:
static int quux_msendl(struct msock_vfs *mvfs,
struct iolist *first, struct iolist *last, int64_t deadline);
static ssize_t quux_mrecvl(struct msock_vfs *mvfs,
struct iolist *first, struct iolist *last, int64_t deadline);
And we have to fill in the virtual function table inside quux_attach()
function:
int quux_attach(int u) {
...
self->mvfs.msendl = quux_msendl;
self->mvfs.mrecvl = quux_mrecvl;
...
}
Return the pointer to the msock
virtual function table when hquery()
is called with msock_type
type ID:
static void *quux_hquery(struct hvfs *hvfs, const void *type) {
struct quux *self = (struct quux*)hvfs;
if(type == msock_type) return &self->mvfs;
if(type == quux_type) return self;
errno = ENOTSUP;
return NULL;
}
Note that quux_msendl()
and quux_mrecvl()
receive pointer to msock virtual function table which is not the same as the pointer to quux object. We'll have to convert it. To make that easier let's define this handy macro. It will convert pointer to an embedded structure to a pointer of the enclosing structure:
#define cont(ptr, type, member) \
((type*)(((char*) ptr) - offsetof(type, member)))
Using the cont
macro we can convert the mvfs
into pointer to quux object. Here, for instance, is a stub implementation of quux_msendl()
function:
static int quux_msendl(struct msock_vfs *mvfs,
struct iolist *first, struct iolist *last, int64_t deadline) {
struct quux *self = cont(mvfs, struct quux, mvfs);
errno = ENOTSUP;
return -1;
}
Add a similar stub implementation for quux_mrecvl()
function and proceed to the next step.
Now that we've spent previous four steps doing boring scaffolding work we can finally do some fun protocol stuff.
Modify the client part of the test program to send a simple text message:
coroutine void client(int s) {
...
int rc = msend(q, "Hello, world!", 13, -1);
assert(rc == 0);
...
}
Function msend
will forward the call to our quux_msendl()
stub function which, at the moment, does nothing but returns ENOTSUP
error. To implement it we have to decide how the quux network protocol will actually look like.
Let's say it will prefix individual messages with 8-bit size. The test message from above is going to look like this on the wire:
Given that size field is a single byte messages can be at most 255 bytes long. That may be a problem in the real world but this is just a tutorial so let's ignore it and move on.
Note that payload data is passed to the quux_msendl()
function in form of two pointers to a structure called iolist
.
Iolists are libdill's alternative to POSIX iovecs. Where iovecs are arrays of buffers (so called scatter/gather arrays) iolists are linked lists of buffers. Very much like iovec, iolist has iol_base
pointer pointing to the data and iol_len
field containing the size of the data. Unlike iovec though it has also iol_next
field which points to the next buffer in the list. iol_next
of the last item in the list is set to NULL
.
An iolist instance may look like this:
Don't forget that there's an extra field in iolist, one called iol_rsvd
, which should be always set to zero.
Given that we decided to prefix quux messages with message size we have to compute the message size first. We can do so by iterating over the iolist and summing all the buffer sizes. If size is greater than 254 (we'll use number 255 for a special purpose later on) it's an error.
size_t sz = 0;
struct iolist *it;
for(it = first; it; it = it->iol_next)
sz += it->iol_len;
if(sz > 254) {errno = EMSGSIZE; return -1;}
Now we can send the size and the payload to the underlying socket:
uint8_t c = (uint8_t)sz;
int rc = bsend(self->u, &c, 1, deadline);
if(rc < 0) return -1;
rc = bsendl(self->u, first, last, deadline);
if(rc < 0) return -1;
To indicate success return zero from the function. Then compile and test.
However, let's suppose we want to implement a high-performance protocol. Looking at the code, it's not hard to spot that there's quite a serious performance problem: For each message, the underlying network stack is traversed twice, one for the size byte, second time for the payload. Instead of doing two send calls and traversing the underlying network stack twice we can modify the iolist to include the size byte as well as the payload and send the entire message using a single bsendl()
call. The modified iolist may look as follows. Grey parts are the original iolist as passed to quux_msendl()
by the user. Black part is the modification done inside quux_msendl()
:
The code will look like this:
uint8_t c = (uint8_t)sz;
struct iolist hdr = {&c, 1, first, 0};
int rc = bsendl(self->u, &hdr, last, deadline);
if(rc < 0) return -1;
Add the lines to receive a message to the test. Note that mrecvl()
function returns size of the message:
int main(void) {
...
char buf[256];
ssize_t sz = mrecv(q, buf, sizeof(buf), -1);
assert(sz >= 0);
printf("%.*s\n", (int)sz, buf);
...
}
To implement the receive function we'll have to read the 8-bit size first:
uint8_t sz;
int rc = brecv(self->u, &sz, 1, deadline);
if(rc < 0) return -1;
Great. Now we know that the message is sz
bytes long. We are going to read those bytes into user's buffers. But let's take care of one special case first.
libdill allows iolist passed to the receive function to be NULL
. What that means is that the user wants to skip a message. This can be easily done given that the underlying protocol provides similar skipping functionality:
if(!first) {
rc = brecv(self->u, NULL, sz, deadline);
if(rc < 0) return -1;
return sz;
}
If the iolist is not NULL
we will find out the overall size of the buffer and check whether message will fit into it:
size_t bufsz = 0;
struct iolist *it;
for(it = first; it; it = it->iol_next)
bufsz += it->iol_len;
if(bufsz < sz) {errno = EMSGSIZE; return -1;}
It the message fits into the buffer payload can be received:
size_t rmn = sz;
for(it = first; it; it = it->iol_next) {
size_t torecv = rmn < it->iol_len ? rmn : it->iol_len;
rc = brecv(self->u, it->iol_base, torecv, deadline);
if(rc < 0) return -1;
rmn -= torecv;
if(rmn == 0) break;
}
return sz;
We are facing the same performance problem here as we did in the send function. Calling brecv()
multiple times means extra network stack traversals and thus decreased performance. And we can apply a similar solution. We can modify the iolist in such a way that it can be simply forwarded to the underlying socket.
The main problem in this case is that the size of the message may not match the size of the buffer supplied by the user. If message is larger than the buffer we will simply return an error. However, if message is smaller than the buffer there's a problem. Bytestream's brecvl()
function has no size argument. It just receives data until the buffer is completely full. Therefore, we will have to shrink the buffer to match the message size.
Let's say the iolist supplied by the user looks like this:
If the message is 5 bytes long we are going to modify the iolist like this. Grey parts are the iolist structures passed to quux socket by the user. Black parts are the modifications:
In iolist-based functions the list is supposed to be unchanged when the function returns. However, it can be temporarily modified while the function is in progress. Therefore, iolists are not guaranteed to be thread- or coroutine-safe.
We are modifying the iolist here, which is all right, but we have to make sure to revert all our changes before the function returns. Note the orig
pointer in the above diagram. It won't be passed to the underlying socket. Instead, it will be used to restore the original iolist after sending is done.
The code for the above looks like this:
size_t rmn = sz;
it = first;
while(1) {
if(it->iol_len >= rmn) break;
rmn -= it->iol_len;
it = it->iol_next;
if(!it) {errno = EMSGSIZE; return -1;}
}
struct iolist orig = *it;
it->iol_len = rmn;
it->iol_next = NULL;
rc = brecvl(self->u, first, last, deadline);
*it = orig;
if(rc < 0) return -1;
return sz;
Compile and run!
Consider the following scenario: User wants to receive a message. The message is 200 bytes long. However, after reading 100 bytes, receive function times out. That puts you, as the protocol implementor, into an unconfortable position. There's no way to push the 100 bytes that were already received back to the underlying socket. libdill sockets provide no API for that, but even in principle, it would mean that the underlying socket would need an unlimited buffer in case the user wanted to push back one terrabyte of data.
libdill solves this problem by not trying too hard to recover from errors, even from seemingly recoverable ones like ETIMEOUT.
When building on top of a bytestream protocol -- which in unrecoverable by definition -- you thus have to track failures and once error happens return an error for any subsequent attampts to receive a message. And same reasoning and same solution applies to outbound messages.
Note that this does not apply when you are building on top of a message socket. Message sockets may be recoverable. Consider UDP. If receiving one packet fails you can still receive the next packet.
Anyway, to implement error handling in quux protocol, let's add two booleans to the socket to track whether sending/receiving had failed already:
struct quux {
...
int senderr;
int recverr;
};
Initialize them to false in quux_attach()
function:
self->senderr = 0;
self->recverr = 0;
Set senderr
to true every time when sending fails and recverr
to true every time when receiving fails. For example:
if(sz > 254) {self->senderr = 1; errno = EMSGSIZE; return -1;}
Finally, fail send and receive function if the error flag is set:
static int quux_msendl(struct msock_vfs *mvfs,
struct iolist *first, struct iolist *last, int64_t deadline) {
struct quux *self = cont(mvfs, struct quux, mvfs);
if(self->senderr) {errno = ECONNRESET; return -1;}
...
}
static ssize_t quux_mrecvl(struct msock_vfs *mvfs,
struct iolist *first, struct iolist *last, int64_t deadline) {
struct quux *self = cont(mvfs, struct quux, mvfs);
if(self->recverr) {errno = ECONNRESET; return -1;}
...
}
Let's say we want to support mutliple versions of quux protocol. When a quux connection is established peers will exchange their version numbers and if those don't match, protocol initialization will fail.
In fact, we don't even need proper handshake. Each peer can simply send its version number and wait for version number from the other party. We'll do this work in quux_attach()
function.
Given that sending and receiving are blocking operations quux_attach()
will become a blocking operation itself and will accept a deadline parameter:
int quux_attach(int u, int64_t deadline) {
...
const int8_t local_version = 1;
int rc = bsend(u, &local_version, 1, deadline);
if(rc < 0) {err = errno; goto error2;}
uint8_t remote_version;
rc = brecv(u, &remote_version, 1, deadline);
if(rc < 0) {err = errno; goto error2;}
if(remote_version != local_version) {err = EPROTO; goto error2;}
...
error2:
free(self);
error1:
hclose(u);
errno = err;
return -1;
}
Note how failure of initial handshake not only prevents initialization of quux socket, it also closes the underlying socket. This is necessary because otherwise the underlying sockets will be left in undefined state, with just half of quux handshake being done.
Modify the test program accordingly (add deadlines), compile and test.
Imagine that user wants to close the quux protocol and start a new protocol, say HTTP, on top of the same underlying TCP connection. For that to work both peers would have to make sure that they've received all quux-related data before proceeding. If they had left any unconsumed data in TCP buffers, the subsequent HTTP protocol would read it and get confused by it.
To achieve that the peers will send a single termination byte (255) each to another to mark the end of the stream of quux messages. After doing so they will read any receive and drop all quux messages from the peer until they receive the 255 byte. At that point all the quux data are cleaned up, both peers have consistent view of the world and HTTP protocol can be safely initiated.
Let's start with addinbg two flags to the quux socket object, one meaning "termination byte was already sent", the other "termination byte was already received":
struct quux {
...
int senddone;
int recvdone;
};
The flags have to be initialized in the quux_attach()
function:
int quux_attach(int u, int64_t deadline) {
...
self->senddone = 0;
self->recvdone = 0;
...
}
If termination byte was already sent send function should return EPIPE
error:
static int quux_msendl(struct msock_vfs *mvfs,
struct iolist *first, struct iolist *last, int64_t deadline) {
...
if(self->senddone) {errno = EPIPE; return -1;}
...
}
If termination byte was already received receive function should return EPIPE
error. Also, we should handle the case when termination byte is received from the peer:
static ssize_t quux_mrecvl(struct msock_vfs *mvfs,
struct iolist *first, struct iolist *last, int64_t deadline) {
...
if(self->recvdone) {errno = EPIPE; return -1;}
...
if(sz == 255) {self->recvdone = 1; errno = EPIPE; return -1;}
...
}
quux_done
function will start the terminal handshake. However, it is not supposed to wait till it is finished. The semantics of the done function are "user is not going to send any more data". You can think of it as of EOF marker of a kind.
int quux_done(int h, int64_t deadline) {
struct quux *self = hquery(h, quux_type);
if(!self) return -1;
if(self->senddone) {errno = EPIPE; return -1;}
if(self->senderr) {errno = ECONNRESET; return -1;}
uint8_t c = 255;
int rc = bsend(self->u, &c, 1, deadline);
if(rc < 0) {self->senderr = 1; return -1;}
self->senddone = 1;
return 0;
}
At this point we can modify quux_detach()
function so that it properly cleans up any leftover protocol data.
First, it will send the termination byte if it was not already sent. Then it will receive and drop messages until it receives the termination byte:
int quux_detach(int h, int64_t deadline) {
int err;
struct quux *self = hquery(h, quux_type);
if(!self) return -1;
if(self->senderr || self->recverr) {err = ECONNRESET; goto error;}
if(!self->senddone) {
int rc = quux_done(h, deadline);
if(rc < 0) {err = errno; goto error;}
}
while(1) {
ssize_t sz = quux_mrecvl(&self->mvfs, NULL, NULL, deadline);
if(sz < 0 && errno == EPIPE) break;
if(sz < 0) {err = errno; goto error;}
}
int u = self->u;
free(self);
return u;
error:
quux_hclose(&self->hvfs);
errno = err;
return -1;
}
Note how the socket, including the underlying socket, is closed when the function fails.
Adjust the test, compile and run.  Have fun writing your own network protocols!


About Me
My name is Jens Blawatt. Currently i work as a
developer and software architect for the GWSmbH
in Münster, Germany.
Professional Career
{{ range .Data.Pages.ByPublishDate }}
{{ partial "career.html" . }}
{{ end }}
{{ partial "footer.html" . }}


Police identify couple fatally shot in their apartment
ST. LOUIS (AP) - Authorities have released the names of two people shot and killed in a northern St. Louis apartment this weekend.
St. Louis County police told the St. Louis Post-Dispatch that 48-year-old Artelia Harold and 51-year-old Bennie Whalen both died Saturday after being shot in their Riverview apartment during a domestic dispute. Harold and Whalen were a couple.
Authorities say it appears that Whalen shot Harold before another adult in the home shot Whalen. That third person called 911 and has been cooperating with police.
Information from: St. Louis Post-Dispatch, http://www.stltoday.com
Sign up for Daily Newsletters
Copyright © 2019 The Washington Times, LLC.
Please read our comment policy before commenting.


Class: Duelist
Duelist Information
The Duelist is Path of Exile's strength/dexterity hybrid class, making him unmatched at dealing and avoiding damage. He can effectively use a shield, but is equally comfortable slashing away with a powerful two-hander or fighting with weapons in both hands. His powerful arms can draw the strings of the heaviest and most lethal longbows. His highly honed reflexes give him a cat-like ability to dodge and parry incoming attacks, be they arrows or axe swings. The Duelist is a daunting foe, and his reputation as a ruthless killer is well deserved. The equipment associated with the Duelist's strength and dexterity are Helmets, Scale/Bridagines/Doublets/Lamellar, Scale Gauntlets, Scale Boots, and Round Shields.
The information above is found on the Path of Exile Wiki Duelist Page along with more information.
Duelist Ascendency
The Duelist has one of three choices for Ascendency: Slayer, Gladiator, Champion.
Slayer
The Slayer class focuses on raw power and maintaining sustainability as they fight. They possess bonuses to life leech and stun and passives such as Bane of Legends gives them an edge against tougher monsters. Due to the minor nodes all having increased attack speed and two-handed damage bonuses, this class is well suited for attack skills for two-handed weapons and bows.
The information above is found on the Path of Exile Wiki Slayer page along with more information.
Gladiator
The Gladiator works well with dual wielding or one-handed weapon and shield combinations. The tree offers opportunities to build around applying bleed and improving the player's blocking.
The information above is found on the Path of Exile Wiki Gladiator page along with more information.
Champion
The Champion is a defensive/support class that can act as a tank for their party by taunting enemies, buffing their allies with an aura, or Intimidate enemies to reduce their defenses. They also have access to passives that grant them offensive bonuses while they have Fortify and uniquely possess the ability to permanently Fortify themselves. The tree grants increased armour and evasion rating across the board to further bolster their survivability as well.
The information above is found on the Path of Exile Wiki Champion page along with more information.
Duelist Builds
The following builds are easy, strong builds that new players can play to learn and progress through the game's current version.
Slayer: Explosion Arrow Slayer
Gladiator: Generic RT Sunder Gladiator
Champion: Dual Wield Frost Blades Champion


{% extends "easydmp/plan/base.html" %} {% load crispy_forms_tags %} {% block content %}
Only a locked plan can be made public, and once made public it cannot be hidden again.
It will become publicly accessible for automated harvesters or anyone else with the link.


"GIER EAGLE" Hebrews raham = “parental affection,” Leviticus 11:18; Deuteronomy 14:17; R.V., “vulture”), a species of vulture living entirely on carrion. “It is about the size of a raven; has an almost triangular, bald, and wrinkled head, a strong pointed beak, black at the tip, large eyes and ears, the latter entirely on the outside, and long feet.” It is common in Egypt, where it is popularly called “Pharaoh’s chicken” (the Neophron percnopterus), and is found in Palestine only during summer. Tristram thinks that the Hebrew name, which is derived from a root meaning “to love,” is given to it from the fact that the male and female bird never part company.
"GIER EAGLE" Hebrews raham = “parental affection,” Leviticus 11:18; Deuteronomy 14:17; R.V., “vulture”), a species of vulture living entirely on carrion. “It is about the size of a raven; has an almost triangular, bald, and wrinkled head, a strong pointed beak, black at the tip, large eyes and ears, the latter entirely on the outside, and long feet.” It is common in Egypt, where it is popularly called “Pharaoh’s chicken” (the Neophron percnopterus), and is found in Palestine only during summer. Tristram thinks that the Hebrew name, which is derived from a root meaning “to love,” is given to it from the fact that the male and female bird never part company.


| Opcode/Instruction | Op/En | 64/32 bit Mode Support | CPUID Feature Flag | Description |
|---|---|---|---|---|
| NP 0F 38 04 /r1 PMADDUBSW mm1, mm2/m64 | A | V/V | SSSE3 | Multiply signed and unsigned bytes, add horizontal pair of signed words, pack saturated signed-words to mm1. |
| 66 0F 38 04 /r PMADDUBSW xmm1, xmm2/m128 | A | V/V | SSSE3 | Multiply signed and unsigned bytes, add horizontal pair of signed words, pack saturated signed-words to xmm1. |
| VEX.128.66.0F38.WIG 04 /r VPMADDUBSW xmm1, xmm2, xmm3/m128 | B | V/V | AVX | Multiply signed and unsigned bytes, add horizontal pair of signed words, pack saturated signed-words to xmm1. |
| VEX.256.66.0F38.WIG 04 /r VPMADDUBSW ymm1, ymm2, ymm3/m256 | B | V/V | AVX2 | Multiply signed and unsigned bytes, add horizontal pair of signed words, pack saturated signed-words to ymm1. |
| EVEX.128.66.0F38.WIG 04 /r VPMADDUBSW xmm1 {k1}{z}, xmm2, xmm3/m128 | C | V/V | AVX512VL AVX512BW | Multiply signed and unsigned bytes, add horizontal pair of signed words, pack saturated signed-words to xmm1 under writemask k1. |
| EVEX.256.66.0F38.WIG 04 /r VPMADDUBSW ymm1 {k1}{z}, ymm2, ymm3/m256 | C | V/V | AVX512VL AVX512BW | Multiply signed and unsigned bytes, add horizontal pair of signed words, pack saturated signed-words to ymm1 under writemask k1. |
| EVEX.512.66.0F38.WIG 04 /r VPMADDUBSW zmm1 {k1}{z}, zmm2, zmm3/m512 | C | V/V | AVX512BW | Multiply signed and unsigned bytes, add horizontal pair of signed words, pack saturated signed-words to zmm1 under writemask k1. |
1. See note in Section 2.4, “AVX and SSE Instruction Exception Specification” in the Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 2A and Section 22.25.3, “Exception Conditions of Legacy SIMD Instructions Operating on MMX Registers” in the Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A.
| Op/En | Tuple Type | Operand 1 | Operand 2 | Operand 3 | Operand 4 |
| A | NA | ModRM:reg (r, w) | ModRM:r/m (r) | NA | NA |
| B | NA | ModRM:reg (w) | VEX.vvvv (r) | ModRM:r/m (r) | NA |
| C | Full Mem | ModRM:reg (w) | EVEX.vvvv (r) | ModRM:r/m (r) | NA |
(V)PMADDUBSW multiplies vertically each unsigned byte of the destination operand (first operand) with the corresponding signed byte of the source operand (second operand), producing intermediate signed 16-bit integers. Each adjacent pair of signed words is added and the saturated result is packed to the destination operand. For example, the lowest-order bytes (bits 7-0) in the source and destination operands are multiplied and the intermediate signed word result is added with the corresponding intermediate result from the 2nd lowest-order bytes (bits 15-8) of the operands; the sign-saturated result is stored in the lowest word of the destination register (15-0). The same operation is performed on the other pairs of adjacent bytes. Both operands can be MMX register or XMM registers. When the source operand is a 128-bit memory operand, the operand must be aligned on a 16-byte boundary or a general-protection exception (#GP) will be generated.
In 64-bit mode and not encoded with VEX/EVEX, use the REX prefix to access XMM8-XMM15.
128-bit Legacy SSE version: The first source and destination operands are XMM registers. The second source operand is an XMM register or a 128-bit memory location. Bits (MAXVL-1:128) of the corresponding destination register remain unchanged.
VEX.128 and EVEX.128 encoded versions: The first source and destination operands are XMM registers. The second source operand is an XMM register or a 128-bit memory location. Bits (MAXVL-1:128) of the corresponding destination register are zeroed.
VEX.256 and EVEX.256 encoded versions: The second source operand can be an YMM register or a 256-bit memory location. The first source and destination operands are YMM registers. Bits (MAXVL-1:256) of the corresponding ZMM register are zeroed.
EVEX.512 encoded version: The second source operand can be an ZMM register or a 512-bit memory location. The first source and destination operands are ZMM registers.
DEST[15-0] = SaturateToSignedWord(SRC[15-8]*DEST[15-8]+SRC[7-0]*DEST[7-0]); DEST[31-16] = SaturateToSignedWord(SRC[31-24]*DEST[31-24]+SRC[23-16]*DEST[23-16]); DEST[47-32] = SaturateToSignedWord(SRC[47-40]*DEST[47-40]+SRC[39-32]*DEST[39-32]); DEST[63-48] = SaturateToSignedWord(SRC[63-56]*DEST[63-56]+SRC[55-48]*DEST[55-48]);
DEST[15-0] = SaturateToSignedWord(SRC[15-8]* DEST[15-8]+SRC[7-0]*DEST[7-0]); // Repeat operation for 2nd through 7th word SRC1/DEST[127-112] = SaturateToSignedWord(SRC[127-120]*DEST[127-120]+ SRC[119-112]* DEST[119-112]);
DEST[15:0]←SaturateToSignedWord(SRC2[15:8]* SRC1[15:8]+SRC2[7:0]*SRC1[7:0]) // Repeat operation for 2nd through 7th word DEST[127:112]←SaturateToSignedWord(SRC2[127:120]*SRC1[127:120]+ SRC2[119:112]* SRC1[119:112]) DEST[MAXVL-1:128] ← 0
DEST[15:0]←SaturateToSignedWord(SRC2[15:8]* SRC1[15:8]+SRC2[7:0]*SRC1[7:0]) // Repeat operation for 2nd through 15th word DEST[255:240]←SaturateToSignedWord(SRC2[255:248]*SRC1[255:248]+ SRC2[247:240]* SRC1[247:240]) DEST[MAXVL-1:256] ← 0
(KL, VL) = (8, 128), (16, 256), (32, 512) FOR j←0 TO KL-1 i←j * 16 IF k1[j] OR *no writemask* THEN DEST[i+15:i]←SaturateToSignedWord(SRC2[i+15:i+8]* SRC1[i+15:i+8] + SRC2[i+7:i]*SRC1[i+7:i]) ELSE IF *merging-masking* ; merging-masking THEN *DEST[i+15:i] remains unchanged* ELSE *zeroing-masking* ; zeroing-masking DEST[i+15:i] = 0 FI FI; ENDFOR; DEST[MAXVL-1:VL] ← 0
VPMADDUBSW __m512i _mm512_maddubs_epi16( __m512i a, __m512i b);
VPMADDUBSW __m512i _mm512_mask_maddubs_epi16(__m512i s, __mmask32 k, __m512i a, __m512i b);
VPMADDUBSW __m512i _mm512_maskz_maddubs_epi16( __mmask32 k, __m512i a, __m512i b);
VPMADDUBSW __m256i _mm256_mask_maddubs_epi16(__m256i s, __mmask16 k, __m256i a, __m256i b);
VPMADDUBSW __m256i _mm256_maskz_maddubs_epi16( __mmask16 k, __m256i a, __m256i b);
VPMADDUBSW __m128i _mm_mask_maddubs_epi16(__m128i s, __mmask8 k, __m128i a, __m128i b);
VPMADDUBSW __m128i _mm_maskz_maddubs_epi16( __mmask8 k, __m128i a, __m128i b);
PMADDUBSW: __m64 _mm_maddubs_pi16 (__m64 a, __m64 b)
(V)PMADDUBSW: __m128i _mm_maddubs_epi16 (__m128i a, __m128i b)
VPMADDUBSW: __m256i _mm256_maddubs_epi16 (__m256i a, __m256i b)
None.
Non-EVEX-encoded instruction, see Exceptions Type 4.
EVEX-encoded instruction, see Exceptions Type E4NF.nb.


Abstract of scientific papers are invited for the NCPCC 2016.
The details are as follows.
Types of Study Both case studies and original research may be presented for posters & or free oral papers. However for free oral papers greater weightage will be given for original research studies.
Word File Submission Please use the Word file Template attached for submission of the abstract. The template has 2 parts. Page 1 is personal details correspondence details & authors list. Page 2 has only the title and the main body of the abstract without names institution of the authors to facilitate blinded peer review of the abstract.
Word Limit The main body of the abstract should be within 250 words single spaced.
Font Type Abstract should be prepared in the given Microsoft Word Template Arial 12 size font with single line spacing typeface with the title in boldface. Do not use all capitals letters.
Tables Abstract should not include tables.
Graphs & Images Abstract should not include graphs and images.
General Instructions It is the author’s responsibility to submit a correct abstract. Any errors in spelling grammar or cientific fact will be reproduced as typed by the author. Do not begin sentences with numerals. Standard abbreviations may be used in the abstract without definition.
Review The scientific committee will review the abstracts and decide the section of presentation poster oral. Registration by the presenting author is mandatory prior to abstract submission.
Time Lines Last date for submission of abstract is 15th August 2016. Notification of acceptance of abstract submitted will be sent by e mail only to the presenting corresponding author on the e mail as given by the authors on or before 10th October 2016.
Submission The abstract submitted online shall only be accepted at email<EMAIL_ADDRESS>No other forms of submission like hard copies fax etc shall be accepted.The soft copy file should be named starting with registration number of the presenting author followed by surname followed by ncpcc2016.doc. In the subject line please write “abstract” .
For clarifications details please contact
<EMAIL_ADDRESS>attn Dr. Milind Tullu & Dr.Preeti Shanbag
Details of the Abstract File
Page 1 of Abstract File This page has details of the authors the title of the paper presenting author abstract word count email of corresponding author etc and should be in the given format template provided for ease of review.
Page 2 of Abstract File This is the main body of the abstract text 250 words. This page should not have any information identifying the authors or their institution. Abstract should be structured & organized to include the following sections.
Background Rationale & Aims Indicate the purpose and objective of the research the hypothesis that was tested or a description of the problem being analyzed or evaluated.
Methods Describe the setting location for the study design study population data collection & methods of analysis used.
Results Present as clearly & detailed as possible the findings outcome of the study with specific results in summarized form. It is not desirable to simply state like “The results will be discussed”.
Discussion The study findings may be correlated with literature evidence.
Conclusion Briefly discuss the data and main outcome of the study.


Organization of the Book
Organization of the Book
Solutions In This Chapter
At the beginning of each chapter a bulleted list of the major topics is provided. This provides a high-level overview of the areas covered within the chapter.
Summary
This section summarizes the most important Solutions covered in the chapter. A brief recap of the information covered within the chapter is provided to give you a chance to go back and review any topic that you may not have found clear the first time around.
Solutions Fast Track
The Solutions Fast Track provides an outline of each topic covered within the chapter. You can use this section as a quick reference guide to quickly check which important facts are covered in each chapter.
Frequently Asked Questions
At the end of each chapter a Frequently Asked Questions, or FAQ, section lists the most common questions associated with the concepts covered in the chapter. These questions were derived from questions posed to the OSSEC mailing list, asked at conferences, or questions the authors felt might be asked in the future.
Chapter Descriptions
Here is a brief overview of the information covered in each chapter:
- Chapter 1: Getting Started With OSSEC
This chapter provides an overview of the features of OSSEC including commonly used terminology, pre-install preparation, and deployment considerations.
- Chapter 2: Installation
This chapter walks through the installation process for the “local”, “agent”, and “server” install types on some of the most popular operating systems available. Techniques to auto- mate multiple agent installations are also covered in depth to ensure a smooth deployment across multiple systems in a large environment.
- Chapter 3: Configuration
This chapter discusses the post-install configuration of OSSEC. Within this chapter you will learn the basic configuration options for your install type and learn how to monitor log files, receive remote messages, configure email notification, and configure alert levels.
- Chapter 4: Working With Rules
This chapter shows you how to extract key information from logs using decoders and how you can leverage rules to alert you of strange occurrences on your network. It includes examples on how to parse atomic and composite rules, how to keep state between messages, how to remove false positives, and how to tune OSSEC appropriately for your network.
- Chapter 5: System Integrity
Check and Rootkit Detection
This chapter explains the system integrity check features of OSSEC, including monitoring binary executable files, system configuration files, and the Microsoft Windows registry.
- Chapter 6: Active Response Configuration
Active response allows you to automatically execute “commands” or responses when a specific event, or a set of events, occur. On the OSSEC HIDS, active response is very scalable, allowing you to execute commands on the agent or on the server side. This chapter explains how to configure the active response actions you want and how to bind the actions to specific rules and sequence of events.
- Chapter 7: Using the OSSEC Web User Interface
This chapter explains how to install, configure, and use the community-developed, open source web interface available for OSSEC.
Epilogue
This chapter concludes the story carried throughout the book and provides some final thoughts from the authors.
Appendix A: Log Data Mining
Dr. Anton Chuvakin, Chief Log Evangalist, LogLogic Inc. This chapter is devoted to log mining or log knowledge discovery - a different type of log analysis, which does not rely on knowing what to look for. This takes the “high art” of log analysis to the next level by breaking the dependence on the lists of strings or patterns to look for in the logs.
Appendix B:
Implementing a Successful OSSEC Policy
Michael J. Santarcangelo, II, Founder and Chief Security Catalyst, The Michaelangelo Group. To be successful in implementing OSSEC in your organization, you need to have an effective policy to guide and support your actions. This appendix will explain the steps you need to take in order to quickly and successfully develop and implement your policy.
Appendix C: Rootkit Detection Using Host-Based IDS
By Peter Giannoulis and Adam Winnington, Information Security Consultants, Access 2 Networks This appendix chapter provides a brief history of rootkits and how host-based IDS solutions can assist in their prevention and detection. The positives and negatives of HIDS technologies are also discussed.
Appendix D: Using the OSSEC VMware Environment
Included with the book is a DVD that contains a pre-configured Ubuntu 7.10 server running the OSSEC HIDS. The OSSEC HIDS VMware Guest image allows you to implement what you have learned in a sandbox-style environment. This appendix explains how the OSSEC HIDS VMware Guest image was create and explains how you can create a OSSEC HIDS VMware Guest image of your own.


--- layout: post title: '' date: 2016-02-27 17:44:25.000000000 +09:00 type: post parent_id: '0' published: true password: '' status: publish categories: [] tags: [] meta: _rest_api_published: '1' _rest_api_client_id: "-1" _publicize_job_id: '20236651275' author: login: mouthless email<EMAIL_ADDRESS>display_name: mouthless first_name: '' last_name: '' ---
“Catch only what you’ve thrown yourself, all is
mere skill and little gain;
but when you’re suddenly the catcher of a ball
thrown by an eternal partner
with accurate and measured swing
towards you, to your center, in an arch
from the great bridgebuilding of God:
why catching then becomes a power—
not yours, a world’s.
—Rainer Maria Rilke”
Excerpt From: Gadamer, Hans-Georg. “Truth and Method.” iBooks.


Nina
Row
Sign out
Games List
Select your game or Upload your own
Upload a new game
File input
Upload your game here
Current Games
ID
Game Name
User
Rows
Cols
Target
Game Variant
Registered Players
Game Status
Actions
Loading Games Data...


This website contains information about the Docker images maintained by the Phenotypic Evolution Group (pegi3s) at the Instituto de Biologia Molecular e Celular (IBMC) / Instituto de Investigação e Inovação em Saúde da Universidade do Porto (i3S). All images are available through our Docker Hub repository, and the respective Docker files at our GitHub repository.
In addition, this repository also contains tutorials to serve as guidance on the usage of existing Docker images (e.g. Trinity for RNA-Seq).
In order to use the Docker images maintained by pegi3s, users need to install Docker first.
To install Docker in Linux, please follow the steps provided here (additional information can be found here).
To install Docker in Windows, please download the official installer Docker for Windows Installer.exe. If your system does not meet the requirements to run Docker for Windows (available here), please install Docker Toolbox instead.
As an alternative and for practical purposes, we provide an Ubuntu 18.04 LTS (Linux) virtual image with 11.8 GB, with Docker and Portainer already installed. Please note that this virtual image is limited to 100 GB. In order to run it, first download VirtualBox here. After installing VirtualBox, users just need to import the OVA file here provided. To import an existing virtual machine into VirtualBox, please follow the steps described here.The administrator's user and password are pegi3s. The username and password for Portainer are pegi3sdocker.
Note: For proper performance, we recommend the use of a machine with at least 8 GB of RAM memory in order to allocate half of that memory (4 GB) to VirtualBox. Using a smaller amount of RAM memory for the virtual machine may cause a very low performance of the entire system.
List of available bioinformatic images:
sudo su
(administrator privileges) is required to run any image. As an alternative please follow the steps described here to manage Docker as a non-root user.docker system prune -a
docker rmi <image_name> or <image_ID>
docker pull pegi3s/<image_name>
Q. Are the Docker images compatible with Singularity?
A. Yes. In principle, all of our images can be run using Singularity. This guide provides some examples.
Q. Are the Docker images compatible with Podman?
A. Yes. In principle, all of our images can be run using Podman. This guide provides some examples.
If you are interested in our project or would like to contribute with suggestions, you may contact us through<EMAIL_ADDRESS>H. López-Fernández; P. Ferreira; M. Reboiro-Jato; C.P. Vieira; J. Vieira (2021) The pegi3s Bioinformatics Docker Images Project. 15th International Conference on Practical Applications of Computational Biology & Bioinformatics: PACBB 2021. Salamanca, Spain. 6 - October
P. Ferreira; H. López-Fernández; P. Duque; Cristina P. Vieira; F. Fdez-Riverola; Miguel Reboiro-Jato; J. Vieira (2019) Bioinformatics Docker Images. Bioinformatics Open Days: BOD 2019. Braga, Portugal. 21 - February
ELIXIR bio.tools: Bioinformatics Docker Images Project.
Follow us on Social Networks:
If you use these Docker Images, please include in the acknowledgments section of your paper the sentence: "The authors wish to thank to the Bioinformatics Docker Images Project (https://pegi3s.github.io/dockerfiles/) and to the BioData.pt Project (https://biodata.pt)".
H. López-Fernández; P. Ferreira; M. Reboiro-Jato; C.P. Vieira; J. Vieira (2021) The pegi3s Bioinformatics Docker Images Project. 15th International Conference on Practical Applications of Computational Biology & Bioinformatics: PACBB 2021. Salamanca, Spain. 6 - October
We are grateful to BioData.pt, funded by project 22231/01/SAICT/2016.


Collection
Amount of products:
281
Amount per page
12
24
36
48
Sort by
Newest
Sale
Price low to high
Price high to low
Title
Brand
€100,-
Lorem ipsum dolor sit amet, consectetur adipiscing elit.


Gas Station Simulation and Monitoring
[
App Admin
|
Pump Simulation
|
Tank Simulation
|
Monitor
]
{{message}}
This site only works when JavaScript is enabled.


Modit connects developers and stakeholders for supercharged agile development
Automatically stage your code as live product versions. You get real-time feedback for rapid iteration towards deployable functionality.
Simplify and centralize your communication. Attach stakeholders feedback and discussion on every revision.
Don’t waste time manually deploying, maintaining and sharing staging environments.
Make stakeholders happier with greater visibility and input. More recognition and more reward.
Every code revision becomes an independant, hosted and runnable product version vs. a single staging environment. It’s your code, live.
Simple 1-time setup. Never waste developer time provisioning, deploying to and maintaining staging. Modit gets your dream app live in a few clicks.
Versions are independent snapshots that run on-demand and live forever, so staging never breaks when your codebase changes.
Invite everyone - PMs, QAs, designers, clients, customers, the public - to review your progress. Never worry about manual permissions, URLs or passwords.
Comments are attached to each version, providing deeper targeted feedback on features, design and bugs for the next iteration.
Directly compare multiple versions: review features in isolation, commits with different feature flags and multiple branches, all at once.
Attach reviewable versions to targets on Modit or stories on your existing PM tool. Definition of done becomes production-ready.
Use staging on its own, or add it to an existing CI / CD workflow. Need help with an integration? All you have to do is ask.
Any type of web application can be made to run on Modit. Most require little to no setup at all. Get started.
| BEFORE MODIT | AFTER MODIT | |
|---|---|---|
| Pain of deploying to/maintaining staging | Fully automated deployments | |
| Coordinate staging on a single environment | Unlimited, parallel staging versions | |
| New commits overwrite & break staging | Independent versions live forever | |
| Manual permissions, URLs and pws | Built-in team sharing and permissions | |
| Scattered, disorganized feedback | Centralized feedback on each version | |
| Ambiguous “definition of done” | “Done” = deployable product version on Modit | |
| Getting single feature to “done” >2 weeks | Single feature to “done” < few days | |
| $30+/month for one instance on AWS/Heroku | $30/month for unlimited staging/dev instances |
“Modit allows us to get feedback and iterate on each individual feature as it’s built, instead of waiting until the end of a sprint.”
“It was a nightmare to deal with separate email threads for client feedback. Modit puts all our communication in one place for easy access.”
“Modit bridges the communication divide with my developers. [I know exactly what they are building.] They understand and deliver exactly what I want.”


Buff
About Us
Login
Welcome to Buff
The Weightlifting Journal
Lift + track = gains
Ready to change your life?
Sign up!


fipe_vehicle.Rd
Access to the Fipe Database
fipe_vehicle(model, make = NULL, year = NULL, date = Sys.Date(), progress = FALSE, parallel = FALSE)
| model | a character vector. Vehicle model name. |
|---|---|
| make | a character vector. If NULL, search all models in all makes, otherwise only those indicated. |
| year | a numeric vector. Year of manufacture of the vehicle. If 0 returns vehicles 0 km. |
| date | a date vector. Reference date for the vehicle price. |
| progress | a logical, if TRUE print a progress bar. |
| parallel | a logical, if TRUE apply function in parallel. |
A data frame/tibble including model, make, year, date and price.
The Fipe Database shows the average purchase price of vehicles in the Brazilian national market. The prices are effectively used in purchase negotiations according to region, vehicle’s conservation, color, accessories or any other factor that might influence the demand and supply for a specific vehicle. The year of the vehicle refers to the model year, and the vehicles are not considered for professional or special use. The values are expressed in R$ (reais) for each month/year of reference.
Official Website https://veiculos.fipe.org.br.
fipe_vehicle( model = "etios platinum", make = "toyota", date = "2019-08-01", year = c(0, 2019, 2018) )#> # A tibble: 6 x 5 #> model make year date price #> <chr> <chr> <fct> <date> <dbl> #> 1 ETIOS PLATINUM 1.5 Flex 16V 4p Aut. Toyota 0 km 2019-08-01 63127 #> 2 ETIOS PLATINUM 1.5 Flex 16V 4p Aut. Toyota 2019 2019-08-01 58616 #> 3 ETIOS PLATINUM 1.5 Flex 16V 4p Aut. Toyota 2018 2019-08-01 54512 #> 4 ETIOS PLATINUM Sed. 1.5 Flex 16V 4p Aut. Toyota 0 km 2019-08-01 66080 #> 5 ETIOS PLATINUM Sed. 1.5 Flex 16V 4p Aut. Toyota 2019 2019-08-01 59610 #> 6 ETIOS PLATINUM Sed. 1.5 Flex 16V 4p Aut. Toyota 2018 2019-08-01 55736


I'm facing a strange problem: I'm using a D18B20 plus a DHT11 with my Spark Core, sending data to my local EmonCMS. Everything works fine...but I can't figure out how to show at least one decimal point for values coming from DHT22, while temperature from D18B20 is correctly formatted.
I don't understand if the problem comes from my sketch on Spark Core, from MySQL database or from some hidden options in EmonCMS.
Anyone can help me? i've been struggling around for a week...
My code:
// This #include statement was automatically added by the Particle IDE.
#include "PietteTech_DHT/PietteTech_DHT.h"// This #include statement was automatically added by the Particle IDE.
#include "spark-dallas-temperature/spark-dallas-temperature.h"// This #include statement was automatically added by the Particle IDE.
#include "OneWire/OneWire.h"#include "application.h"
#include "HttpClient/HttpClient.h"#define DHTTYPE DHT11 // Sensor type DHT11/21/22/AM2301/AM2302
#define DHTPIN D3 // Digital pin for communications
#define DHT_SAMPLE_INTERVAL 2000 // Sample every two seconds
//declaration
void dht_wrapper(); // must be declared before the lib initialization// Lib instantiate
PietteTech_DHT DHT(DHTPIN, DHTTYPE, dht_wrapper);/**
Declaring the variables.
*/
#define TOKEN "7327a3859afda46ba2eb1d326b7b1d1e1251922f"
#define ONE_WIRE_BUS D2
double temperature = 0.0;
int light = 0;
float h = 0.0;
float t = 0.0;bool bDHTstarted; // flag to indicate we started acquisition
unsigned int nextTime = 0; // Next time to contact the server
OneWire oneWire(ONE_WIRE_BUS);
DallasTemperature sensor(&oneWire);
HttpClient http;// Headers currently need to be set at init, useful for API keys etc.
http_header_t headers[] = {
{ "Content-Type", "application/json" },
{ "X-Auth-Token" , TOKEN },
{ "Accept" , "*/*"},
{ NULL, NULL } // NOTE: Always terminate headers will NULL
};http_request_t request;
http_response_t response;void setup() {
Spark.variable("temp", &temperature, DOUBLE);
Spark.variable("light", &light, INT);
//Spark.variable("humidity", &h, DOUBLE);sensor.begin();
sensor.setResolution(12);
//dht.begin();
Serial.begin(9600);
}void dht_wrapper() {
DHT.isrCallback();
}void loop() {
if (nextTime < millis()) {if (!bDHTstarted) { // start the sample
Serial.println("Retrieving information from sensor: ");
DHT.acquire();
bDHTstarted = true;
}
if (!DHT.acquiring()) { // has sample completed?
// get DHT status
int result = DHT.getStatus();Serial.print("Read sensor: ");
switch (result) {
case DHTLIB_OK:
Serial.println("OK");
break;
case DHTLIB_ERROR_CHECKSUM:
Serial.println("Error\n\r\tChecksum error");
break;
case DHTLIB_ERROR_ISR_TIMEOUT:
Serial.println("Error\n\r\tISR time out error");
break;
case DHTLIB_ERROR_RESPONSE_TIMEOUT:
Serial.println("Error\n\r\tResponse time out error");
break;
case DHTLIB_ERROR_DATA_TIMEOUT:
Serial.println("Error\n\r\tData time out error");
break;
case DHTLIB_ERROR_ACQUIRING:
Serial.println("Error\n\r\tAcquiring");
break;
case DHTLIB_ERROR_DELTA:
Serial.println("Error\n\r\tDelta time to small");
break;
case DHTLIB_ERROR_NOTSTARTED:
Serial.println("Error\n\r\tNot started");
break;
default:
Serial.println("Unknown error");
break;
}
Serial.print("Humidity (%): ");
h = DHT.getHumidity();
Serial.println(h, 2);Serial.print("Temperature (oC): ");
t = DHT.getCelsius();
Serial.println(t, 2);Serial.print("Temperature (oF): ");
Serial.println(DHT.getFahrenheit(), 2);Serial.print("Temperature (K): ");
Serial.println(DHT.getKelvin(), 2);Serial.print("Dew Point (oC): ");
Serial.println(DHT.getDewPoint());Serial.print("Dew Point Slow (oC): ");
Serial.println(DHT.getDewPointSlow());bDHTstarted = false; // reset the sample flag so we can take another
/////}sensor.requestTemperatures();
temperature = sensor.getTempCByIndex(0);
light = analogRead(A0);request.hostname = "xxxxxxxxxxxx.noip.me";
request.port = 80;
request.path = "/emoncms/input/post.json?apikey=04ee49a2498f7eb7b1aab7a54a27257a&node=1&json={temp:" + String(temperature) + ",tempDHT11:" + String(t) + ",light:" + String(light) + ",humidity:" + String(h) + "}";http.post(request, response, headers);
nextTime = millis() + 30000;
}
}
}
Re: Floating point not shown
Assuming the Serial.prints are reporting correctly, have you tried using "String(t, 2)" and "String(h, 2)" in your request string.
Paul
Re: Floating point not shown
You are right about Serial.print.
Just had a try with String(t,1)...no joy!
...
request.path = "/emoncms/input/post.json?apikey=04ee49a2498f7eb7b1aab7a54a27257a&node=1&json={temp:" + String(temperature) + ",tempDHT11:" + String(t,1) + ",light:" + String(light) + ",humidity:" + String(h,1) + "}";
...
(where can I find infos about code formatting on this forum?)
Re: Floating point not shown
Can you add something like Serialln.print(request.path) to see the populated request string over serial?
I wouldn't know where to point you regards the code tips as we don't really send floats from a sketch that often, you could look at some NanodeRF sketches or search Arduino Ethernet shield, maybe.
I checked the arduino site for the correct String format https://www.arduino.cc/en/Reference/StringConstructor
Paul
Re: Floating point not shown
Serial is ok: I set 2 decimal values for Temp, one for Humidity, and that's it
Retrieving information from sensor:
Read sensor: OK
Humidity (%): 36.0
Temperature (oC): 21.00
Temperature (oF): 69.80
Temperature (K): 294.15
Dew Point (oC): 5.35
Dew Point Slow (oC): 5.38
/emoncms/input/post.json?apikey=04ee49a2498f7eb7b1aab7a54a27257a&node=1&json={temp:21.500000,tempDHT11:21.00,light:735,humidity:36.0}
Retrieving information from sensor:
Read sensor: OK
Humidity (%): 36.0
Temperature (oC): 21.00
Temperature (oF): 69.80
Temperature (K): 294.15
Dew Point (oC): 5.35
Dew Point Slow (oC): 5.38
/emoncms/input/post.json?apikey=04ee49a2498f7eb7b1aab7a54a27257a&node=1&json={temp:21.562500,tempDHT11:21.00,light:928,humidity:36.0}
Retrieving information from sensor:
Read sensor: OK
Humidity (%): 36.0
Temperature (oC): 21.00
Temperature (oF): 69.80
Temperature (K): 294.15
Dew Point (oC): 5.35
Dew Point Slow (oC): 5.38
/emoncms/input/post.json?apikey=04ee49a2498f7eb7b1aab7a54a27257a&node=1&json={temp:21.500000,tempDHT11:21.00,light:1023,humidity:36.0}
Also JSON string is ok...but:
hey, "...The DHT11 does not provide decimal parts. It outputs zero's. ...",
here the explanation: http://forum.arduino.cc/index.php?topic=57058.0
So...end of story!
thanks anyway!


| PostgreSQL 9.0.10 Documentation | ||||
|---|---|---|---|---|
| Prev | Up | Chapter 54. Database Physical Storage | Next |
Each heap and index relation, except for hash indexes, has a Free Space Map (FSM) to keep track of available space in the relation. It's stored alongside the main relation data in a separate relation fork, named after the filenode number of the relation, plus a _fsm suffix. For example, if the filenode of a relation is 12345, the FSM is stored in a file called 12345_fsm, in the same directory as the main relation file.
The Free Space Map is organized as a tree of FSM pages. The bottom level FSM pages store the free space available on each heap (or index) page, using one byte to represent each such page. The upper levels aggregate information from the lower levels.
Within each FSM page is a binary tree, stored in an array with one byte per node. Each leaf node represents a heap page, or a lower level FSM page. In each non-leaf node, the higher of its children's values is stored. The maximum value in the leaf nodes is therefore stored at the root.
See src/backend/storage/freespace/README for more details on how the FSM is structured, and how it's updated and searched. The contrib/pg_freespacemap module can be used to examine the information stored in free space maps (see Section F.26).


Patient Personal Information
Patient's Details
Patient Name
Health ID
National Identification No
Gender
Age
Est.
Blood Group
Marital Status
Occupation
Educational Level
Atdress
Post Office
Police Station
District
Division


[ Select Previous Object
] Select Next Object
W A S D Pan Camera
R Move Camera Up
F Move Camera Down
← → Yaw Camera
↑ ↓ Pitch Camera
Currently selected: