(This article was originally published in PC AI magazine, Volume 9, Number 3 May/June 1995. The magazine can be reached at PC AI, 3310 West Bell Rd., Suite 119, Phoenix AZ, USA 85023 Tel<PHONE_NUMBER>, FAX:<PHONE_NUMBER>.)
This article uses a classic Prolog programming example to illustrate how Prolog back-end services can be integrated with C++ front-end user interface code. The sample application is genealogy, with Prolog providing rules for family relationships and C++ the GUI interface to the application. The connection between the two is encapsulated in a C++ class that provides application-specific Prolog services to the rest of the C++ application.
For this application the Prolog code provides four types of logic services to the host application. The first two are basically the same type of services a database can provide.  The second two services draw on Prolog's strength for rule-based programming. They are: 1) answering queries about relationships in the data, and 2) providing semantic integrity checks on entered and updated data. For those who haven't spent much time in the database world, semantic integrity checks go beyond normal input- field validation. In this case, for example, they check to see if a person in the database is their own ancestor. If that is true, the individual data records might be valid, but the database does not make semantic sense as a genealogical tree.
Let's look at these four sections.
This sample genealogical code has been written many times for many beginning Prolog books. While they all have the same types of rules for relationships, those rules are always based on some fundamental information. The choice of what is fundamental and what is derived varies from program to program. For this version of the program, I've decided the primitive fact will be person/5, where the five arguments are: Name, Gender, Mother, Father, Spouse. Because this is a decision that might change in the future, only a few primitive relationship rules are defined using the knowledge of the basic person information.
These relations are:
person(X) :- person(X,_,_,_,_). male(X) :- person(X,male,_,_,_). female(Y) :- person(Y,female,_,_,_). mother(M,C) :- person(C,_,M,_,_). father(F,C) :- person(C,_,_,F,_). parent(P,C) :- (mother(P,C) ; father(P,C)). spouse(S,P) :- person(P,_,_,_,S), S \= single.
By building all of the other rules on these basic building blocks, it becomes easy to add or modify the basic data structure. For example, if we wanted to keep the date-of-birth for a person, that change would only impact these basic definitions.
The next service provided by the Prolog program is maintenance of the collection of persons in a family. These predicates add a new person, delete a person, load the person database from file, and save it back to file. The add/5 predicate is designed to back out an update on backtracking, so that it can be easily used by the semantic integrity checking add_person/5 predicate.
add(Name,Gender,Mother,Father,Spouse):- assert(person(Name,Gender,Mother,Father,Spouse)). add(Name,_,_,_,_) :- delete(Name), fail. delete(Name) :- retract(person(Name, _, _, _, _)). save(FileName) :- tell(FileName), listing(person), told. open(FileName) :- consult(FileName).
Like the rules providing access to individual person data, these rules provide access to the family database. For this example, the person data is stored in the Prolog database, using asserts and retracts.
We now get to the rule-base portion of the application. These query rules allow more complex information to be derived from the data. These are all the classic rules for grandparents, siblings, uncles, aunts, ancestors, etc. Some examples of these rules are shown here. Notice that they all build on the same set of primitive information so that changes to the underlying structure of the data in the application will not affect the relationship rule-base.
ancestor(A,P) :- parent(A,P). ancestor(A,P) :- parent(X,P), ancestor(A,X).
full_sibling(S1, S2) :- mother(M,S2), mother(M,S1), S1 \= S2, father(F,S1), father(F,S2).
uncle(U,X) :- parent(P,X), brother(U,P).
aunt(A,X) :- parent(P,X), sister(A,P).
The query rule-base has one additional fact that can be used by the host program. It contains a list of all the defined relationships.
relations([parent, wife, husband, ancestor, .....]).
It can be used in a generic relationship rule that can find out how two people are related, among other things.
relation(R, X, Y) :- relations(Rs), member(R,Rs), Q =.. [R,X,Y], call(Q).
The final service the Prolog module provides is semantic integrity checking. This means checking a proposed update or change to the database against the rest of the database to ensure it makes sense. Examples include checking: a person's mother and father are the right gender, someone is not their own ancestor, and spouses are not blood relatives. While this last is not really a genealogical rule, I've included the rule as an example of relatively complex semantic integrity checking on a database.
Here are some of the rules from the integrity rule-base portion of the Prolog code. Because this Prolog code is designed to be passively called from a host application, error messages are simply asserted to the database for the host program to retrieve in case an update fails. (Alternatively it could have been designed to take a more active role in the application, calling the host program directly when an error occurs.)
add_person(Name,Gender,Mother,Father,Spouse) :- retractall(message(_)), dup_check(Name), add(Name,Gender,Mother,Father,Spouse), ancestor_check(Name), mother_check(Name, Gender, Mother), father_check(Name, Gender, Father), spouse_check(Name, Spouse).
ancestor_check(Name) :- ancestor(Name,Name), assert(message($Person is their own ancestor/descendent$)), !, fail. ancestor_check(_).
spouse_check(Name, Spouse) :- spouse(Name, X), X \= Spouse, assert(message($Person is already someone else's spouse$)), !, fail. spouse_check(Name, Spouse) :- blood_relative(Name, Spouse), assert(message($Person is a blood relative of spouse$)), !, fail. spouse_check(_,_).
blood_relative(X,Y) :- (ancestor(X,Y); ancestor(Y,X)). blood_relative(X,Y) :- sibling(X,Y). blood_relative(X,Y) :- cousin(X,Y). blood_relative(X,Y) :- (uncle(X,Y); uncle(Y,X)). blood_relative(X,Y) :- (aunt(X,Y); aunt(Y,X)).
As we can see from the above discussion, the Prolog code for this application is in four distinct sections. Two sections clearly behave as objects. These are the individual person object, and the collection of persons, or family object. The rules that manipulate these objects are all localized in the code. The other two sections are rule-bases that reason over the objects. One provides queries looking for relationships in the collection, and the other provides queries that verify relationships between persons are as they should be. In the next section we'll talk about encapsulating the entire Prolog program and its services as a C++ object that can be part of a larger application.
For this example, the Prolog services will be accessed from a Windows C++ program that provides a GUI interface to the user. The GUI interface will let the user load and save family databases, use list-boxes to pose relationship queries, and use dialog-boxes to update the family database.
C++ is well suited to GUI programming, as it allows for the natural encapsulation of the various objects that comprise the interface. In this example, there are objects that correspond to each of the dialogs the application has with the user.
C++ is also well-suited for interfacing with Prolog, as it enables the application programmer to implement an object that encapsulates the Prolog services. In this way the C++ interface to the Prolog services is well defined, and the implementation can be maintained without impacting the rest of the application.
The example code was implemented using Microsoft Visual C++, the Microsoft Foundation Classes, and the Amzi! Prolog Logic Server API, however, these same ideas apply to any C++ implementation, GUI tool-kit, and Prolog with a host language interface.
A C++ header file defines the interface to C++ classes. Because the program maps person information between C++ and Prolog, the C++ program first defines a structure called Person.
struct Person { CString name; CString mother; CString father; CString spouse; CString genderS; };
It will be used to hold and pass person information in the C++ portion of the program. (CString is a string class defined in the MFC. Other C++ vendors provide similar classes.)
Next, consider the class that defines the interface to the Prolog portion of the code. It is called ProGene, and in this case is derived from a vendor-provided class that provides generic Prolog services. The ProGene class extends those generic services with functions particular to this specific Prolog program.
class ProGene : public CLSEngine { public: ProGene(); // constructor initializes Prolog and loads program ~ProGene(); // destructor cleans up Prolog environment
// Manipulate the family database BOOL Open(const char *); BOOL Save(); // Save the current family file
// Map Prolog generated information to list-boxes BOOL Persons(CList-box *); BOOL Relationships(CList-box *); BOOL Answers(CList-box *, char * relation, char * name);
// Provide update services BOOL PersonData(Person *); BOOL AddPerson(); BOOL DelPerson(char *); BOOL SaveValid(Person *);
// Process Prolog errors private: void PrologError(char * s, RC rc = 0); };
Because the Prolog services might be available to a number of other classes, a global object is created for the Prolog object. When the application starts up, the object is created, and when the application closes down, the object is destroyed. This is all done automatically by one line of code in the beginning of the program.
ProGene proGene; // Interface to Prolog Program
Let's now look at some of the code that makes use of this interface.
First a family file must be opened. This is done by using the File/Open menu choice of the application which causes the following code to be executed. The code uses the familiar Windows file open dialog to let the user select a file containing a family tree. That file name is then passed to the Prolog server, which opens the file.
void GeneWnd::OnFileOpen() { CString sFile;
// Use the file open dialog to get a file name CFileDialog fileDlg(TRUE, ".fam", NULL,.... ... if (fileDlg.DoModal() != IDOK) return; sFile = fileDlg.GetPathName();
// Call the Prolog server to open a family database file bOpen = proGene.Open((const char *)sFile); }
Once the database is open, it is ready to be queried about family relationships. The query dialog-box contains the three list-boxes shown in the screen image. The first list-box is initialized with the names of the individuals in the family, and the second with the possible relationships. The third list-box is filled with the results of queries constructed from choices in the first and second list-boxes.
In each case, the query dialog simply passes a pointer to a list- box to the proGene server object, which then populates the list- box with the appropriate information.
BOOL QueryDlg::OnInitDialog() { CList-box *lb; // get first list-box pointer lb = (CList-box*)GetDlgItem(IDC_LIST1); // fill the list-box if (!proGene.Persons(lb)) return FALSE; // second list-box pointer lb = (CList-box*)GetDlgItem(IDC_LIST2); // fill it as well if (!proGene.Relationships(lb)) return FALSE; ...}
The queries are posed by selecting a name and relationship from the first two list-boxes. That data is passed to the Prolog server, which then populates the 'answers' list-box with the returned relatives. Because all of the information for the list- boxes is derived from the Prolog program, any changes to the Prolog data, additions of new relationships, etc. is all done in Prolog.
afx_msg void QueryDlg::OnDoQuery() { CList-box *lbNames, *lbRelations, *lbAnswers; char name[NAMELEN]; char relation[NAMELEN];
... // extract relation and name from first two list-boxes // and pass information to server proGene.Answers(lbAnswers, relation, name);
The last point of interest is the update dialog. After the user has entered the fields of a new person record, this function maps the dialog-box data to C++ variables, in this case the person structure defined earlier. This example includes some of the automatic field validation capabilites of the Microsoft Foundation Classes, but these validation edits only apply to field specific attributes such as length of a name, value of a number etc.
The full semantic integrity checking is provided by the 'SaveValid' function of the proGene Prolog server. This function passes the proposed new record to Prolog to either add to the database, or report an error causing the user to have to try again.
void EditDlg::DoDataExchange(CDataExchange *pDX) { DDX_Text(pDX, IDC_EDIT1, m_person.name); DDV_MaxChars(pDX, m_person.name, NAMELEN); ... // call Prolog to verify and update if (! proGene.SaveValid(&m_person)) // use MFC failure mechanism if integrity checks failed pDX->Fail();
Notice that these code fragments simply maintain the user interface widgets of the application. They put up list-boxes, respond to buttons, get selected values from list-boxes, but nowhere have any "understanding" of what is contained in the user interface. That information is provided entirely by the Prolog portion of the application.
Conversely, the Prolog code has no "understanding" of the type of user interface being employed. It provides the services asked of it.
The user interface C++ code and rule-based Prolog code are cleanly isolated from each other, with the proGene server object providing the communication between them.
Finally, we'll look inside the Prolog server object to see how it connects C++ to the genealogical Prolog code. This particular example uses the Amzi! Prolog Logic Server API functions to call Prolog from C, but similar code can be implemented with any Prolog that provides a C interface.
The open is accomplished by sending a 'consult' query to the Prolog engine with the name of the file (containing a family tree) to be opened.
BOOL ProGene::Open(const char * sFile) { // build a query string sprintf(buf, "consult('%s')", sFile); // call Prolog with the string tf = CallStr(&t, buf); ...
The persons list-box is populated by finding all answers to the Prolog query 'person(X)' and adding those answers to the list-box.
BOOL ProGene::Persons(CList-box *lb) { tf = CallStr(&t,"person(X)"); // pose the initial query while(tf) { GetArg(t, 1, cSTR, buf); // get the answer from the query lb->AddString(buf); // add it to the list-box tf = Redo(); // redo the query until it fails } return TRUE; }
The relations list-box is similarly populated by getting the list of all relationships (from the relations/1 fact we saw earlier) and popping elements from the list into the list-box.
BOOL ProGene::Relationships(CList-box *lb) { TERM tList; tf = CallStr(&t, "relations(X)"); // pose the query if (tf) { GetArg(t, 1, cTERM, &tList); // get the answer list while (OK == PopList(&tList, cSTR, buf)) // pop each element lb->AddString(buf); } return TRUE; }
The answers list-box works similar to the persons list-box. In this case a more complex query is posed, and then redone until all of the answers have been retrieved and placed in the answer list- box.
BOOL ProGene::Answers(CList-box *lb, char * relation, char * name) { sprintf(buf, "%s(X,'%s')", relation, name); // build the query tf = CallStr(&t, buf); //pose the query while (tf) { GetArg(t, 1, cSTR, buf); // get the first argument answer lb->AddString(buf); // add it to the list-box tf = Redo(); // get the next answer } return TRUE; }
The final piece to look at here is the code that performs the semantic integrity checking and update of the database. It also builds a Prolog query that calls add_person/5, which either adds the record or posts an error message. This code picks up the error message if the integrity checks fail, displays it for the user and then lets the caller deal with the error situation.
BOOL ProGene::SaveValid(Person *p) { char errmsg[BUFLEN]; sprintf(buf,"add_person('%s', '%s', '%s', '%s', '%s')", (const char *)p->name, (const char *)p->genderS, (const char *)p->mother, (const char *)p->father, (const char *)p->spouse); tf = CallStr(&t, buf); if (tf == FALSE) { CallStr(&t, "message(X)"); GetArg(t, 1, cSTR, errmsg); sprintf(buf, "Semantic Integrity Error:\n%s", errmsg); AfxMessageBox(buf); return FALSE; } return TRUE; }
These are the highlights of the Prolog server interface that provide a clean insulating layer between the Prolog code containing the basic logic of the application and the user interface code written in C++.
This sample application illustrates how the object-oriented capabilities
of C++ can be used to create a clean bridge between C++ code and Prolog
code. The resulting design allows C++ to be used for those aspect of an
application its best suited for, and Prolog for those aspects its best
suited for. C++ is used with Microsoft's GUI tools to develop a Windows
front end, while Prolog is used as both a database and a rule-base. The
architecture makes it easy to maintain the logic rules of the application,
coded in declarative Prolog, and the GUI interface using the increasingly
sophisticated GUI tools available from C++ vendors. The link between the
two components is neatly encapsulated in a C++ object.


---
layout: archive
title: Lean Prover Zulip Chat Archive
permalink: 113488general/67859uniquetyping.html
---
The archive URL format has changed. Please find this page at:
https://leanprover-community.github.io/archive/stream/113488-general/topic/unique.20typing.html


Mark Bottomley
Links Design Patterns and embedded systems, but excludes user interfaces, describing it as 'a large area'.
"The world has thousands of applications running on millions of micro-controllers that utilize
simple executives or “bare metal” applications."
"The solution space includes process controllers, consumer boxes (e.g. VCRs, microwaves, stoves,
etc.), automotive modules, and many other applications. These systems often have limited user
interaction, accept data from a variety of sensor inputs, and control a few outputs."
"The preceding is the core of The Carousel pattern language for simple embedded systems.
Further extensions to this language should include patterns covering initialization, shutdown, processing
optimizations (particularly replacing floating point and trigonometric calculations), error reporting, and
the large area of user interfaces."
Unread


Chern Runner
Runners
impression ID
status
size
{% for impression in impressions %}
{{ impression.id }}
{{ impression.status }}
impression.size
{% endfor %}


Scrolls in a higher frequency of scrollbar by mouse.
Refresh delay: apply the refresh delay to the option selected.


Thank you for helping with transcribing data for the 1915 Iowa state census! This was the first census in the United States to record information on education and earnings, making it a uniquely helpful document for economic researchers to understand that era. (See here for more details.)
The current project is part of an ongoing effort by a group of researchers (see "about us" at the bottom) to understand Mobility in the United States during the depression era. To this end, we are interested in transcribing people's earnings, occupations and property values. The example below describes the fields we need transcribed:
Here's a card from the 1915 Iowa census, with the 9 fields we want to enter indicated. Of the 9 fields, only "Occupation" is a string. All others are (or should be!) numbers. For instance, Card no. is 1324, not B24! (Don't worry, we chose a difficult card as an example)
Earnings is the annual earnings in 1914 (in $). This might be recorded with $ or ,'s or other things but we just need the numbers. If there is a word written here instead (like unemployed), write that instead. Fred Reynolds earned $800 in 1914.
Occupation is a string that indicates what job the person had. In this case, Fred Reynolds was a Farmer. (Laborer and Housekeeper are two other common occupations in the data). This field might be hard to read, but do your best.
The extent of education was asked in four categories: Common School, Grammar School, High School, and College. Not everyone will have years of all four categories, so just enter the years they report a number for and skip any with dashes or blanks. In this card, Fred Reynolds has 8 years of common school and 3 years of high school and nothing else. Some records may have a single number that spans both Common and Grammar lines. For these, enter the number in Common ONLY.
Like Earnings, these values should both be dollar amounts. In Fred's case, the Incumbrance on his farm or home is $2500, and the value of his farm/home is $10000. Usually, these values are only populated if the answer to a previous question ("Do you own your home or farm") is yes. But we don't you to fill in that question.
If a field is empty on the card, or if there's a dash or a blank drawn through it (as shown), please leave it empty on the form. For numeric fields (such as income) only enter "0" if it is explicitly written on the card.
Enter "-1" if a field (of any type) is illegible or hard to read.
The principle investigators of the current study are:
James Feigenbaum, Boston University (corresponding author. Email<EMAIL_ADDRESS>Maximillan Hell, Stanford University
Robert Manduca, Harvard University
Jimmy Narang, University of California, Berkeley
The current study is made possible in part by a grant from the Russell Sage Foundation (RSF Award#: 83-17-21)


--- layout: archive title: Zulip Chat Archive permalink: /stream/113489-new-members/topic/Lean.20to.20Z3.html ---
Recently I read the presention “From Lean to Z3”，I want to ask some questions，has lean integrated Z3 so far？
Nope
There used to exist some work towards this, but it is not compatible with the current version of Lean
Thank you
{% endraw %}Last updated: Apr 24 2020 at 19:02 UTC


Ive researched for awhile and I couldnt find much info on Fetanyl.  At first I didnt think much of a drug which you take by sucking on a lollipop. But it would teach me lesson.
To start off I would like to say I have used pretty much every drug
imaginable. My favorite is opiates. But in my experience with those I've yet to come across Fentanyl. Until when I was on vacation in Orlando, Florida with a good buddy of mine. His brother had recently had all the skin de-gloved from his right leg and was given Fentanyl lollipops called Actiqs for when he was to change his bandages.
One night my buddy 'V' came home with three Actiqs and five 40mg Oxycontin. We had about an ounce of regular grade pot and we where set for a nice evening. We agreed that we would split everything up farely and evenly. Since he and I have had a past of fighting over drugs we always take certain precautions to avoid those situations. Plus pain killers can make us both irretiable. So anyways we decided that I would get 2 Actiqs and 2 Oxycontin for the evening. While he would have the left over lollipop and 3 Oxycontin. So we were set.
V explained that the best way to dose on the lollipop was to stick up in the very corner of the mouth and to twirl fast till it desolved.   But I certainly didnt want to waste it. While doing this we were driving around in the car and we decided to stop at a local grocery store parking lot to break up the first Oxycontin of the night. I decide it would be best to wait since I was dosing on the Fentanyl and I wasnt sure how I would react. So I finished off the gross rasberry tasting lollipop and was already noticable fucked. My eyes were half close and blood shot. Which was weird cause I hadnt even smoked a bowl yet. I felt a strong Pain killer high. But I wasnt as fucntional as I usually am on pain killers.
V had just snorted about 80mgs of Oxycontin and we decided to walk around the grocery store.  I was hardly functional. We walked around forever. I lost complete track of time. I found myself just staring off at nothing and daydreaming. I can hardly remember that whole grocery store deal but I remember having to run from the store manager because V had been caught stealing.
 Then without even realizing it I finished off the other Actiq. I remember being in this zombie like daze and hearing V say, 'What the fuck, you already ate both of them?'. I didnt realize it.  I was FUCKED.
We arrived at V's mom's house where I stumbled in and fell on the couch. I was soooooooo tired. V broke up about 80mgs of Oxycontin and I snorted a 40mg line. Damn!  I remember smoking some pot out of the gravity bong and being real itchey.
Next thing I know V' mom is waking me up to help her with something first thing I do is run into the bathroom and hurl my guts out.  Puking ever hour or so. I'd try to eat but about 15 minutes later I would puke it up. V was also sick from snorting about 100 something mgs of Oxycontin that night. so all day we both went through hell. But honestly it was worth it. I doubt I'll ever see anythere Actiq ever again. But if I do I'll defiantly do it. I just think I went alittle over-board the first time.
PEACE
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.


The theft was discovered Thursday morning after the Akron Beacon Journal’s staff moved from the paper’s former building.
The Akron Beacon Journal reports the thief took the medal from a protective display case where it was stored in the former newsroom lobby. The medal was scheduled to be moved to the next office.
Police say the medal was stolen sometime between Tuesday and late Thursday morning.
Akron Beacon Journal Publisher Bill Albrecht says the paper is cooperating with the investigation.
The medal was awarded for the paper’s 1994 “A Question of Color” series.
Information from: Akron Beacon Journal, http://www.ohio.com
Sign up for Daily Newsletters
Copyright © 2019 The Washington Times, LLC.
Please read our comment policy before commenting.


--- layout: home ---
My name is Maddy and I'm 8 years old. I love pandas and my dad. I play footy and ride my scooter. I like writing stories and doing arts and crafts.
I sometimes write on my blog or write about experiments I do at home and school. You can also visit my Moshi Monsters Room Thanks for visiting, bye.


Changes the chart type for a selected data series, a group of data series, or an entire chart.
Syntax
FORMAT.CHARTTYPE(apply_to, group_num, dimension, type_num)
FORMAT.CHARTTYPE?(apply_to, group_num, dimension, type_num)
Apply_to is a number from 1 to 3 specifying what part of a chart the new chart type effects.
| Value | Part of chart |
| 1 | Selected data series |
| 2 | Group of data series |
| 3 | Entire chart |
Group_num corresponds to the number of the group you want to change as listed in the Group list box of the Chart Type dialog box, which appears when you click Chart Type from the Format menu while a chart is active. Groups are numbered starting with 1 for the group at the top of the list. This argument is required if apply_to equals 2; otherwise it is ignored.
Dimension specifies whether to apply a 2-D or 3-D chart type. Use 1 for a 2-D chart type or 2 for a 3-D chart type. If omitted, uses the same dimension as the series, group, or chart to be changed.
Type_num specifies the chart type to apply. Meaning of type_num varies depending on the value of dimension:
| Type_num | Chart type if dimension is 1 |
| 1 | Area or 3-D area |
| 2 | Bar or 3-D bar |
| 3 | Column or 3-D column |
| 4 | Line or 3-D line |
| 5 | Pie or 3-D pie |
| 6 | Doughnut or 3-D surface |
| 7 | Radar |
| 8 | XY (scatter) |
Related Function
FORMAT.CHART Formats the selected chart
Return to index


Faces Flow example: Registration
Executing any none flow actions will leave current flow, there is a bug in the early version of Majorra and it is fixed in 2.2.3.


Hello, my name is Kaisma and I was born and raised on Tortola, British Virgin Islands. I love to code!
Visit the sources page a list of resources I find useful in the coding journey.


{% extends "mdotdevs/base.html" %} {% block title %}Building Apps Home{% endblock %} {% block content %}
Ready to submit your app for inclusion in the UW Development App Stores? Does it meet our publishing guidelines?
If so, please fill out the form below. We will review your app and let you know the next steps.


Previous: Earley items, Up: Terms [Contents][Index]
An application behavior is a behavior on which it is intended that the design of applications will be based. In this document, a behavior is an application behavior unless otherwise stated. We sometimes say that “applications may expect” a certain behavior to emphasize that that behavior is an application behavior.
After an irrecoverable failure, the behavior of a Libmarpa application is undefined, so that there are no behaviors that can be relied on for normal application processing, and therefore, there are no application behaviors. In this circumstance, some of the application behaviors become diagnostic behaviors. A diagnostic behavior is a behavior that this document suggests that the programmer may attempt in the face of an irrecoverable failure, for purposes of testing, diagnostics and debugging. Diagnostic behaviors are hoped for, rather than expected, and intended to allow the programmer to deal with irrecoverable failures as smoothly as possible. (See Failure.)
In this document, a behavior is a diagnostic behavior only if that is specifically indicated. Applications should not be designed to rely on diagnostic behaviors. We sometimes say that the application “may attempt” a certain behavior to emphasize that that behavior is a diagnostic behavior.


It is your choice whether or not you wish to participate in this research. If you choose to participate, you can change your mind and leave the study at any time. Refusal to participate, or stopping your participation, will involve no penalty or loss of benefits to which you are otherwise entitled.
The purpose of this research is to find out if and how students make use of an alternative navigation system for course materials.
Your participation shouldn’t be more than two hours over the course of one semester. However if the system is useful to you, feel free to use it more often as long as your course performance is not negatively influenced.
After logging in into the system you will be able to navigate through the Gov2001 course material. You can consume different types of media (lecture slides, video, scientific publications, Wikipedia, etc.). During your visit we will log your clicks to see if the system design supports interaction. During the semester we will improve the system and will ask you to fill in questionnaires.
There is minimal risk to participating in this study. You might be more efficient in learning using the slides and videos of the original webpage than spending the time with the new system. The information you provide is anonymous and you are free to withdraw from participation at any time.
We do not expect any direct benefits to you from taking part in this research. No one who grades the course will know whether or not you used this system.
You might get a better overview of the course structure. One indirect benefit of participating might be the knowledge that you helped researchers to better understand if and how a non-linear learning system would benefit users.
There will be no compensation.
All data collected from you will be coded with a number that makes it very hard to infer your identity. The results of this research project might be made public, with information quoted in professional journals and meetings. However, no personal information will be released and all information from this study will only be reported as a group and not individually.
No one who grades the course will know whether or not you used this system.
Any information with your name on it will be analyzed by the researcher(s) and may be reviewed by people checking to see that the research has been conducted properly.
The researcher for this study is
Hendrik Strobelt, who can be reached at<PHONE_NUMBER> or at<EMAIL_ADDRESS>The faculty sponsor is Hanspeter Pfister, who can be reached at<PHONE_NUMBER> or<EMAIL_ADDRESS>If you have questions, concerns, or complaints, then please get in touch:This research has been reviewed by the
Committee on the Use of Human Subjects in Research at Harvard University. They can be reached at<PHONE_NUMBER>, 1414 Massachusetts Avenue, Second Floor, Cambridge, MA 02138, or<EMAIL_ADDRESS>for any of the following:I have read the information in this consent form. All my questions about the research have been answered to my satisfaction.
If you consent to participate, please click “I consent to participate” below.


What is the name of this place?
Where is it located?
In which province is it located?
How to get to get to this place?
Can you explain more about this place?
Enter the URL of the photo ypu want to upload


Biden on Deported Veterans: 'Bring Them Back' | Breitbart
by Ian HanchettDuring a town hall on CNN on Monday, 2020 Democratic presidential candidate former Vice President Joe Biden stated that he would bring veterans who were deported to their native countries after serving back to the United States.
Biden was asked how he would “help veterans who served honorably, but then were deported back to their native country?”
Biden responded, “Bring them back. … It’s outrageous what they did, outrageous what the president did.”
He continued by discussing swearing in soldiers who weren’t U.S. citizens before stating, “We are a country of immigrants, and they served, and they should be treated the same way.”
Follow Ian Hanchett on Twitter @IanHanchett


Hi everyone ! My name is Boudrique Dorian. I am 33 years old. After multiple professional experiences in software development, I am currently searching for a position as a developer.
Learn More !Goal summary :
Programming features and tools for Calypso software.
Features :
Creation selections of multipacking for storekeeper.
Creation of filters for lists and searching lists.
Creation of basics about a telemarketing modulo for a client.
SQL Queries using PDO.
Programming languages : PHP, Javascript, JQuery, HTML5, CSS3.
Technologies : Ajax.
Databases:MySQL, SQLServer, use of JSON.
Concepts : OOP.
Tools : Teams, Eclipse PHP, Click, Heidi SQL.
Softwares:Calypso, M4go.
Goal summary :
Monitoring the classrooms and the exteriors.
Features :
School Monitor at the Lycée Stendhal de Milan.
Monitoring the classrooms.
Administrative works.
Goal summary :
Client supports and database administration, developping softwares app based on client's demands.
Features :
Ticket management using phonecalls, mails and TeamViewer.
Sage and Cegid softwares installation.
Database support and handling.
SQL Queries and SQL Jobs.
App creation using Visual Basics and .NET.
Programming languages : Visual Basics, .NET. , SQL Jobs, Batch, Windows Tasks.
Softwares:Sage, Cegid, Pack office.
Databases:MySQL, Access, SQLite.
Virutalizaion tools : VMWare.
Tools : TeamViewer.
Goal summary :
Creation of a showcase website for a pizzeria. Here !
Features :
Creation a showcase website from scratch.
Users stories writings in order to conform to client's expectations.
Conception of the pages ( Home, Menu, Contact).
Programming languages : HTML5, CSS3, PHP.
Tools : Visual Studio Code, WAMPServer.
Goal summary :
Creation of my personnal website : Go !
Features :
Creating a showcase web site ( Home page, contact page, projects page).
Programming languages : HTML5, CSS3, PHP.
Goal summary :
Collaboration to a creation of a booking app and website services.
Features :
Participation to the creation of an existent project.
UML diagrams and project analysis.
Front-end web development ( design, forms ).
Back-end web development ( Users registration, online payment, mailing service ).
Multilingual application.
Prepublication using Plesk.
Programming languages : PHP, Javascript, JQuery, HTML5, CSS3.
Technologies : Doctrine, Twig, Bootstrap.
Framework : Symfony.
Databases:MySQL.
Concepts : OOP, ORM.
Tools : Plesk, PHPStorm, Trello.
Goal summary :
Learning the basics about Syfmony and MVC achitecture.
Features :
Basics understanding about Model Viewer Controller applications.
Learning about Symfony architecture.
Creation and management of database using MySQL/WAMP.
Documentation and unit tests.
Transfert to a native website in HTML5/CSS3 to a symfony environment.
Prepublication using Plesk.
Programming languages : PHP, Javascript, HTML5, CSS3.
Technologies : Doctrine, Twig, Bootstrap, WAMPServer.
Framework : Symfony.
Databases:MySQL.
Concepts : OOP, ORM.
Tools : Visual studio code, PhpMyAdmin, Gantt.
Goal summary :
Creation of a to do list dashboard.
Features :
Creation of a project from stratch.
User stories writings.
UML diagrams and project analysis using StarUML.
Creation of the website design using Balsamiq Mock-up.
Conception of the forms, design, pages, lists and tasks services.
Registration and user management (login, password, verification, security).
Responsive design ( monitor screen, smartphone, tablets).
Creation of an android app from the project using Android Studio.
Programming languages : PHP, Javascript, Jquery, HTML5, CSS3.
Technologies : WAMPServer.
Databases:MySQL.
Concepts : OOP.
Tools : Visual studio code, Balsamiq Mockup, PhpMyAdmin, StarUML, Gantt.
Goal summary :
Creation of a role-playing game based on Advanced Dungeons and Dragons rules.
Features :
Creation of a project from stratch.
User stories writings.
UML diagrams and project analysis using StarUML.
Creation of the website design using Balsamiq Mock-up.
Conception of the forms, design, pages, creation of a character, creation of a map..
Registration and user management (login, password, verification, security).
Link the app to a database using JDBC.
Programming languages : Java, JDBC.
Databases:MySQL.
Concepts : OOP.
Tools : Eclipse, Balsamiq Mockup, StarUML, Gantt.
Goal summary :
Innership in a start-up : Front-End & Back-End Development.
Features :
Learning Python Basics.
Front-end development ( FOBI forms, User Interface).
Back-end development ( GPS tracking from MyEneo maps using Leaflet 2 libraries ).
Programming languages : Javascript, Python.
Framework:Django.
Concepts : OOP.
OS: Linux (Ubuntu).
Features :
Cleaning the dishes and the kitchens.
Features :
Counting of the ballot papers.
Sorting the postal envelopes.
Archiving.
Goal summary :
Reception and make the tour of the Grotte de la Devèze.
Features :
Multilingual visits of the Grotte de la Devèze.
Management of tourist groups.
Waiter.
Languages : French, English, Italian, German.
Goal summary :
Innership in a robotic laboratory : Creating an application to make a dialogue between human and robot.
Features :
Learning the basics of programming using C, C++.
Use of language recognition software: Pockersphinx.
Creation of scenarios.
Programming languages : C
Tools :Latex.
OS : Linux.
Software : Pocketsphinx.
Goal summary :
Innership in a linguistic laboratory : Recording the seminaries and maintain a podcasting website.
Features :
Recordings linguistic seminaries with camera.
Editing the videos using FinalCutExpress and IMovie ( generics, subtitles, sequences).
Upload the datas on a podcast website.
Administrative tasks ( notes about meetings, creation of flyers).
OS : IOS.
Softwares : IMovie, FinalCutExpress, InDesign.
Features :
400 hours of job training.
Comprehension and application on SAGE software i7.
Comprehension and application on CEGID Gamme Suite.
Ticket supervising and client support.
Features :
Basics understanding of pseudo code.
Basics understanding of SQL queries.
Creation of websites linked to a database.
Creation of apps linked to a database.
Database creation/managment.
Programming languages : C#, HTML5, CSS3, Java.
Versionning : Git.
Methods : Agile, Scrum.
Features :
Basics and understandings about Massive Online Open Courses (MOOC).
Conception of online courses for students (using Moodle, Claroline).
Writings of two memoirs ( " The evolution of the natural language throughout the centuries : A first approach about the relatives between the natural language and the artificial language through robotic " , " An interactionnist approach of artificial intelligence : the revelance of the human-robot dialogue ").
Research works about artificial intelligence, robotics and linguistic litteratures.
Features :
Courses about lingustic, sentence forming and comprehension of native speaker.
Features :
Bachelor degree in Litterature. Grade : Fair.
PHP, HTML5, CSS3, Javascript, JQuery.
Visual Basics, .NET, C#, Java.
SQL, MySQL, SQLite, Access, PhpMyAdmin, SQL Jobs, Windows tasks.
Symfony, Doctrine, Twig, WAMPServer.
Levels of languages.
A list of my hobbies and my social networks.
Ready for hiring me ? Give me a call or send me an email and I will get back to you as soon as possible!


This page allows you to register on-line as a patron of our library. You will have limited privileges.
Why do you need to provide your birthdate? The Library uses your birthdate to determine the services that are available to you and also provides compliance with the CIPA laws governing online access


Geodesy Group Inc.
45361049
2015/07/29
859 Other business services not elsewhere specified
2015/07/29 to 2016/11/30
2016/11/30
$52,447.50
Digital Aerial Imagery Mount Revelstoke and Glacier NPs
This contract is a multi-year contract


{{square.isKing ? 'K' : ''}}
Player Turn : {{player}}
Red Score : {{redScore}}
Black Score : {{blackScore}}


React Socket Simple Chat
Socket.io server is running
[GitHub] erkobridee / react-socket-simple-chat
React Socket Simple Chat - application


The usual pronunciation of vase, in this country, is as a rhyme with mars. In the United States, it is more common for vase to rhyme with lace. Growing up on an Essex council estate with a Belgian mother whose native tongue was Flemish, however, I learned to rhyme vase with jaws.
This was but one example of my mother's idiosyncratic English. She spoke of the old films we loved to watch as being “in white and black”, and regularly deployed a sort of guttural expostulation my sister still refers to as “the Flemish sound”. This was used to express a vast swathe of emotions, from surprise to incredulity to contempt to disgust to … well, pretty much any response.
The word chasm is one that we probably encounter more in written than spoken English. My mother pronounced it with a soft ch, as in chase or chicken. So I did too, on the rare occasions I said it aloud. I only learned the correct, hard c pronunciation in my late teens, when I was reading a passage aloud in an English class at school and my teacher raised an amused eyebrow. He gently corrected me when I finished reading.
Many years have passed, but I still find myself drawn inexorably to the pronunciations I learned at my mother's knee. And, intriguingly, my sister finds herself increasingly using “the Flemish sound” as she grows older.


Below is the what I remember to be a good way to solve a technical problem :-
- Listen Carefully
- Draw an Example
- Give Brute Force/Obvious Solution
- Walk Through the Algorithm
- Implement
- Test
Below is the what I remember to be good ways to optimize solution to a technical problem :-
- BUD ie Bottleneck, Unnecessary Work, Duplicated Work
- DIY ie Work through a representative example
- Simplify and Generalize
- Base case and Build
- Data Structure Brainstorm


Tests the following part of the contract:
The packer delivers either a legal loading plan that contains at
least one package for each transport or no loading plan at all.
Tests the following part of the contract:
The packer delivers either a legal loading plan that contains at
least one package for each transport or no loading plan at all.
Tour qualities are used for acceleration
of check process, where for each tour on
the giant tour a associated tour quality
holds the costs and penalties.


|
LibDriver W25QXX
1.0.0
W25QXX full function driver
|
w25qxx basic driver modules More...
Data Structures | |
| struct | w25qxx_handle_s |
| w25qxx handle structure definition More... | |
| struct | w25qxx_info_s |
| w25qxx information structure definition More... | |
Typedefs | |
| typedef struct w25qxx_handle_s | w25qxx_handle_t |
| w25qxx handle structure definition More... | |
| typedef struct w25qxx_info_s | w25qxx_info_t |
| w25qxx information structure definition More... | |
Enumerations | |
| enum | w25qxx_type_t { W25Q80 = 0XEF13 , W25Q16 = 0XEF14 , W25Q32 = 0XEF15 , W25Q64 = 0XEF16 , W25Q128 = 0XEF17 , W25Q256 = 0XEF18 } |
| w25qxx type enumeration definition More... | |
| enum | w25qxx_interface_t { W25QXX_INTERFACE_SPI = 0x00 , W25QXX_INTERFACE_QSPI = 0x01 } |
| w25qxx interface enumeration definition More... | |
| enum | w25qxx_bool_t { W25QXX_BOOL_FALSE = 0x00 , W25QXX_BOOL_TRUE = 0x01 } |
| w25qxx bool enumeration definition More... | |
| enum | w25qxx_address_mode_t { W25QXX_ADDRESS_MODE_3_BYTE = 0x00 , W25QXX_ADDRESS_MODE_4_BYTE = 0x01 } |
| w25qxx address mode enumeration definition More... | |
Functions | |
| uint8_t | w25qxx_info (w25qxx_info_t *info) |
| get chip's information More... | |
| uint8_t | w25qxx_set_dual_quad_spi (w25qxx_handle_t *handle, w25qxx_bool_t enable) |
| enable or disable the dual quad spi More... | |
| uint8_t | w25qxx_get_dual_quad_spi (w25qxx_handle_t *handle, w25qxx_bool_t *enable) |
| get the dual quad spi status More... | |
| uint8_t | w25qxx_set_type (w25qxx_handle_t *handle, w25qxx_type_t type) |
| set the chip type More... | |
| uint8_t | w25qxx_get_type (w25qxx_handle_t *handle, w25qxx_type_t *type) |
| get the chip type More... | |
| uint8_t | w25qxx_set_interface (w25qxx_handle_t *handle, w25qxx_interface_t interface) |
| set the chip interface More... | |
| uint8_t | w25qxx_get_interface (w25qxx_handle_t *handle, w25qxx_interface_t *interface) |
| get the chip interface More... | |
| uint8_t | w25qxx_set_address_mode (w25qxx_handle_t *handle, w25qxx_address_mode_t mode) |
| set the chip address mode More... | |
| uint8_t | w25qxx_get_address_mode (w25qxx_handle_t *handle, w25qxx_address_mode_t *mode) |
| get the chip address mode More... | |
| uint8_t | w25qxx_init (w25qxx_handle_t *handle) |
| initialize the chip More... | |
| uint8_t | w25qxx_deinit (w25qxx_handle_t *handle) |
| close the chip More... | |
| uint8_t | w25qxx_read (w25qxx_handle_t *handle, uint32_t addr, uint8_t *data, uint32_t len) |
| read data More... | |
| uint8_t | w25qxx_write (w25qxx_handle_t *handle, uint32_t addr, uint8_t *data, uint32_t len) |
| write data More... | |
| uint8_t | w25qxx_only_spi_read (w25qxx_handle_t *handle, uint32_t addr, uint8_t *data, uint32_t len) |
| read only in the spi interface More... | |
| uint8_t | w25qxx_fast_read (w25qxx_handle_t *handle, uint32_t addr, uint8_t *data, uint32_t len) |
| read in the fast mode More... | |
| uint8_t | w25qxx_page_program (w25qxx_handle_t *handle, uint32_t addr, uint8_t *data, uint16_t len) |
| page program More... | |
| uint8_t | w25qxx_sector_erase_4k (w25qxx_handle_t *handle, uint32_t addr) |
| erase the 4k sector More... | |
| uint8_t | w25qxx_block_erase_32k (w25qxx_handle_t *handle, uint32_t addr) |
| erase the 32k block More... | |
| uint8_t | w25qxx_block_erase_64k (w25qxx_handle_t *handle, uint32_t addr) |
| erase the 64k block More... | |
| uint8_t | w25qxx_chip_erase (w25qxx_handle_t *handle) |
| erase the chip More... | |
| uint8_t | w25qxx_power_down (w25qxx_handle_t *handle) |
| power down More... | |
| uint8_t | w25qxx_release_power_down (w25qxx_handle_t *handle) |
| release power down More... | |
| uint8_t | w25qxx_get_manufacturer_device_id (w25qxx_handle_t *handle, uint8_t *manufacturer, uint8_t *device_id) |
| get the manufacturer && device id information More... | |
w25qxx basic driver modules
| typedef struct w25qxx_handle_s w25qxx_handle_t |
w25qxx handle structure definition
| typedef struct w25qxx_info_s w25qxx_info_t |
w25qxx information structure definition
w25qxx address mode enumeration definition
| Enumerator | |
|---|---|
| W25QXX_ADDRESS_MODE_3_BYTE | 3 byte mode |
| W25QXX_ADDRESS_MODE_4_BYTE | 4 byte mode |
Definition at line 93 of file driver_w25qxx.h.
| enum w25qxx_bool_t |
w25qxx bool enumeration definition
| Enumerator | |
|---|---|
| W25QXX_BOOL_FALSE | false |
| W25QXX_BOOL_TRUE | true |
Definition at line 84 of file driver_w25qxx.h.
| enum w25qxx_interface_t |
w25qxx interface enumeration definition
| Enumerator | |
|---|---|
| W25QXX_INTERFACE_SPI | spi interface |
| W25QXX_INTERFACE_QSPI | dspi qspi interface |
Definition at line 75 of file driver_w25qxx.h.
| enum w25qxx_type_t |
w25qxx type enumeration definition
| Enumerator | |
|---|---|
| W25Q80 | w25q80 |
| W25Q16 | w25q16 |
| W25Q32 | w25q32 |
| W25Q64 | w25q64 |
| W25Q128 | w25q128 |
| W25Q256 | w25q256 |
Definition at line 62 of file driver_w25qxx.h.
| uint8_t w25qxx_block_erase_32k | ( | w25qxx_handle_t * | handle, |
| uint32_t | addr | ||
| ) |
erase the 32k block
| [in] | *handle | points to a w25qxx handle structure |
| [in] | addr | is the erase address |
Definition at line 5420 of file driver_w25qxx.c.
| uint8_t w25qxx_block_erase_64k | ( | w25qxx_handle_t * | handle, |
| uint32_t | addr | ||
| ) |
erase the 64k block
| [in] | *handle | points to a w25qxx handle structure |
| [in] | addr | is the erase address |
Definition at line 5759 of file driver_w25qxx.c.
| uint8_t w25qxx_chip_erase | ( | w25qxx_handle_t * | handle | ) |
erase the chip
| [in] | *handle | points to a w25qxx handle structure |
Definition at line 1459 of file driver_w25qxx.c.
| uint8_t w25qxx_deinit | ( | w25qxx_handle_t * | handle | ) |
close the chip
| [in] | *handle | points to a w25qxx handle structure |
Definition at line 7175 of file driver_w25qxx.c.
| uint8_t w25qxx_fast_read | ( | w25qxx_handle_t * | handle, |
| uint32_t | addr, | ||
| uint8_t * | data, | ||
| uint32_t | len | ||
| ) |
read in the fast mode
| [in] | *handle | points to a w25qxx handle structure |
| [in] | addr | is the read address |
| [out] | *data | points to a data buffer |
| [in] | len | is the data length |
Definition at line 3635 of file driver_w25qxx.c.
| uint8_t w25qxx_get_address_mode | ( | w25qxx_handle_t * | handle, |
| w25qxx_address_mode_t * | mode | ||
| ) |
get the chip address mode
| [in] | *handle | points to a w25qxx handle structure |
| [out] | *mode | points to a address mode buffer |
Definition at line 405 of file driver_w25qxx.c.
| uint8_t w25qxx_get_dual_quad_spi | ( | w25qxx_handle_t * | handle, |
| w25qxx_bool_t * | enable | ||
| ) |
get the dual quad spi status
| [in] | *handle | points to a w25qxx handle structure |
| [out] | enable | points to a bool value buffer |
Definition at line 196 of file driver_w25qxx.c.
| uint8_t w25qxx_get_interface | ( | w25qxx_handle_t * | handle, |
| w25qxx_interface_t * | interface | ||
| ) |
get the chip interface
| [in] | *handle | points to a w25qxx handle structure |
| [out] | *interface | points to a chip interface buffer |
Definition at line 280 of file driver_w25qxx.c.
| uint8_t w25qxx_get_manufacturer_device_id | ( | w25qxx_handle_t * | handle, |
| uint8_t * | manufacturer, | ||
| uint8_t * | device_id | ||
| ) |
get the manufacturer && device id information
| [in] | *handle | points to a w25qxx handle structure |
| [out] | *manufacturer | points to a manufacturer buffer |
| [out] | *device_id | points to a device id buffer |
Definition at line 1952 of file driver_w25qxx.c.
| uint8_t w25qxx_get_type | ( | w25qxx_handle_t * | handle, |
| w25qxx_type_t * | type | ||
| ) |
get the chip type
| [in] | *handle | points to a w25qxx handle structure |
| [out] | *type | points to a chip type buffer |
Definition at line 238 of file driver_w25qxx.c.
| uint8_t w25qxx_info | ( | w25qxx_info_t * | info | ) |
get chip's information
| [out] | *info | points to a w25qxx info structure |
Definition at line 8547 of file driver_w25qxx.c.
| uint8_t w25qxx_init | ( | w25qxx_handle_t * | handle | ) |
initialize the chip
| [in] | *handle | points to a w25qxx handle structure |
Definition at line 6820 of file driver_w25qxx.c.
| uint8_t w25qxx_only_spi_read | ( | w25qxx_handle_t * | handle, |
| uint32_t | addr, | ||
| uint8_t * | data, | ||
| uint32_t | len | ||
| ) |
read only in the spi interface
| [in] | *handle | points to a w25qxx handle structure |
| [in] | addr | is the read address |
| [out] | *data | points to a data buffer |
| [in] | len | is the data length |
Definition at line 3466 of file driver_w25qxx.c.
| uint8_t w25qxx_page_program | ( | w25qxx_handle_t * | handle, |
| uint32_t | addr, | ||
| uint8_t * | data, | ||
| uint16_t | len | ||
| ) |
page program
| [in] | *handle | points to a w25qxx handle structure |
| [in] | addr | is the programming address |
| [in] | *data | points to a data buffer |
| [in] | len | is the data length |
Definition at line 4570 of file driver_w25qxx.c.
| uint8_t w25qxx_power_down | ( | w25qxx_handle_t * | handle | ) |
power down
| [in] | *handle | points to a w25qxx handle structure |
Definition at line 1792 of file driver_w25qxx.c.
| uint8_t w25qxx_read | ( | w25qxx_handle_t * | handle, |
| uint32_t | addr, | ||
| uint8_t * | data, | ||
| uint32_t | len | ||
| ) |
read data
| [in] | *handle | points to a w25qxx handle structure |
| [in] | addr | is the read address |
| [out] | *data | points to a data buffer |
| [in] | len | is the data length |
Definition at line 7270 of file driver_w25qxx.c.
| uint8_t w25qxx_release_power_down | ( | w25qxx_handle_t * | handle | ) |
release power down
| [in] | *handle | points to a w25qxx handle structure |
Definition at line 1875 of file driver_w25qxx.c.
| uint8_t w25qxx_sector_erase_4k | ( | w25qxx_handle_t * | handle, |
| uint32_t | addr | ||
| ) |
erase the 4k sector
| [in] | *handle | points to a w25qxx handle structure |
| [in] | addr | is the erase address |
Definition at line 5081 of file driver_w25qxx.c.
| uint8_t w25qxx_set_address_mode | ( | w25qxx_handle_t * | handle, |
| w25qxx_address_mode_t | mode | ||
| ) |
set the chip address mode
| [in] | *handle | points to a w25qxx handle structure |
| [in] | mode | is the address mode |
Definition at line 304 of file driver_w25qxx.c.
| uint8_t w25qxx_set_dual_quad_spi | ( | w25qxx_handle_t * | handle, |
| w25qxx_bool_t | enable | ||
| ) |
enable or disable the dual quad spi
| [in] | *handle | points to a w25qxx handle structure |
| [in] | enable | is a bool value |
Definition at line 175 of file driver_w25qxx.c.
| uint8_t w25qxx_set_interface | ( | w25qxx_handle_t * | handle, |
| w25qxx_interface_t | interface | ||
| ) |
set the chip interface
| [in] | *handle | points to a w25qxx handle structure |
| [in] | interface | is the chip interface |
Definition at line 259 of file driver_w25qxx.c.
| uint8_t w25qxx_set_type | ( | w25qxx_handle_t * | handle, |
| w25qxx_type_t | type | ||
| ) |
set the chip type
| [in] | *handle | points to a w25qxx handle structure |
| [in] | type | is the chip type |
Definition at line 217 of file driver_w25qxx.c.
| uint8_t w25qxx_write | ( | w25qxx_handle_t * | handle, |
| uint32_t | addr, | ||
| uint8_t * | data, | ||
| uint32_t | len | ||
| ) |
write data
| [in] | *handle | points to a w25qxx handle structure |
| [in] | addr | is the write address |
| [in] | *data | points to a data buffer |
| [in] | len | is the data length |
Definition at line 8396 of file driver_w25qxx.c.


Name: {{ job.job_name }}
School: {{ job.job_school }}
Degree: {{ job.job_degree }}
Major: {{ job.job_major }}
Salary: {{ job.job_salary }}
Count: {{ job.job_count }}
Info: {{ job.job_info }}
Enterprise: {{ job.job_enterprise }}
Return to job list


Deployment engineering for Puma
Puma
expects to be run in a deployed environment eventually. You can use it as
your development server, but most people use it in their production deployments.
To that end, this document serves as a foundation of wisdom regarding deploying
Puma
to production while increasing happiness and decreasing downtime.
Specifying Puma
Most people will specify Puma
by including gem "puma"
in a Gemfile, so we'll
assume this is how you're using Puma
.
Single vs. Cluster mode
Initially, Puma
was conceived as a thread-only web server, but support for
processes was added in version 2.
To run puma
in single mode (i.e., as a development environment), set the
number of workers to 0; anything higher will run in cluster mode.
Here are some tips for cluster mode:
MRI
- Use cluster mode and set the number of workers to 1.5x the number of CPU cores in the machine, starting from a minimum of 2.
- Set the number of threads to desired concurrent requests/number of workers. Puma defaults to 5, and that's a decent number.
Migrating from Unicorn
- If you're migrating from unicorn though, here are some settings to start with:
- Set workers to half the number of unicorn workers you're using
- Set threads to 2
- Enjoy 50% memory savings
- As you grow more confident in the thread-safety of your app, you can tune the workers down and the threads up.
Ubuntu / Systemd (Systemctl) Installation
See systemd.md
Worker utilization
How do you know if you've got enough (or too many workers)?
A good question. Due to MRI's GIL, only one thread can be executing Ruby code at
a time. But since so many apps are waiting on IO
from DBs, etc., they can
utilize threads to use the process more efficiently.
Generally, you never want processes that are pegged all the time. That can mean there is more work to do than the process can get through. On the other hand, if you have processes that sit around doing nothing, then they're just eating up resources.
Watch your CPU utilization over time and aim for about 70% on average. 70% utilization means you've got capacity still but aren't starving threads.
Measuring utilization
Using a timestamp header from an upstream proxy server (e.g., nginx
or
haproxy
) makes it possible to indicate how long requests have been waiting for
a Puma
thread to become available.
- Have your upstream proxy set a header with the time it received the request:
- nginx:
proxy_set_header X-Request-Start "${msec}";
- haproxy >= 1.9:
http-request set-header X-Request-Start t=%[date()]%[date_us()]
- haproxy < 1.9:
http-request set-header X-Request-Start t=%[date()]
- nginx:
- In your
Rack
middleware, determine the amount of time elapsed sinceX-Request-Start
. - To improve accuracy, you will want to subtract time spent waiting for slow
clients:
env['puma.request_body_wait']
contains the number of milliseconds Puma spent waiting for the client to send the request body.- haproxy:
%Th
(TLS handshake time) and%Ti
(idle time before request) can can also be added as headers.
Should I daemonize?
The Puma 5.0 release removed daemonization. For older versions and alternatives, continue reading.
I prefer not to daemonize my servers and use something like runit
or systemd
to monitor them as child processes. This gives them fast response to crashes and
makes it easy to figure out what is going on. Additionally, unlike unicorn
,
Puma
does not require daemonization to do zero-downtime restarts.
I see people using daemonization because they start puma directly via Capistrano
task and thus want it to live on past the cap deploy
. To these people, I say:
You need to be using a process monitor. Nothing is making sure Puma
stays up in
this scenario! You're just waiting for something weird to happen, Puma
to die,
and to get paged at 3 AM. Do yourself a favor, at least the process monitoring
your OS comes with, be it sysvinit
or systemd
. Or branch out and use runit
or hell, even monit
.
Restarting
You probably will want to deploy some new code at some point, and you'd like
Puma
to start running that new code. There are a few options for restarting
Puma
, described separately in our restart documentation.


Landing Page
Special Projects
This story is part of a series of specially designed stories that represents some of the best journalism The Post has to offer. Check out the rest of the special projects here.
MEAGAN HALL
09.07.17
When the third president of Ohio University, Robert G. Wilson, gave his inaugural address on Aug. 11, 1828, he outlined the importance of each subject to an education.
He stressed how important it was to “rouse the native energies of the mind” and told the crowd about why students should still learn the dead languages, according to a transcript of his speech.
Nearly 200 years later, Duane Nellis, OU’s 21st president, presented his main goals at the convocation for first-year students on Aug. 27 — goals that strongly differed from Wilson’s speech while sharing the same message about the importance of a university education.
“Universities address change in nearly everything we do.” Robert Glidden, OU’s 19th president
Throughout the university’s history, presidents have delivered a variety of inaugural and convocation addresses, each tailored to and representative of the differences in leadership over the years.
Alex Penrose | FILE
President Duane Nellis spoke to the incoming freshman at the Convocation Center Sunday prior to the Involvement fair on Campus.
Some topics, such as the importance of individualized education, carried through speeches throughout time, but as university presidents faced a variety of problems and circumstances, their speeches changed with them.
When Roderick McDavis, the university’s 20th president, spoke at his inaugural address on Sept. 10, 2004, he outlined his goals of making OU a prominent university, increasing diversity, securing national resources and increasing relationships in the area.
Decades earlier, when John Calhoun Baker stepped up to speak during his inaugural address on May 11, 1945, OU’s 14th president had more to address than just university goals. During his tenure, he also had to face the aftermath of World War II.
He highlighted four points that he thought should be the goals of higher education: development of character, training for citizenship, careers and leadership, and leisure.
“When the history of this period is written, we will not be judged by the variety of courses offered, by educational fads adopted, by the number of students enrolled, nor by the attractiveness of the buildings, but by the quality and character of our graduates and their contributions to society,” Baker said in his inaugural address.
Thirty years later, on March 6, 1976, Charles J. Ping, the 18th OU president, delivered an inaugural address that one university benefactor said was so good that he thought it should have been redistributed to every university president in the country, according to a March 8, 1976, Post article by Joe Kay.
In his address, Ping emphasized the importance of professional development and the university’s place to teach both to large groups and to each person.
That devotion to individualized teaching and providing education to a large group of people was present in many speeches, including Vernon Alden’s inauguration as the 15th OU president.
Alden said in his May 11, 1962, inaugural address that he wanted to cast a “wide admissions net” and also hoped to push “ill-prepared, poorly motivated individuals” in addition to challenging the “outstanding student.” That is why one of his proposals included the creation of a full honors college, and an increased number of doctoral programs.
On Oct. 1, 1994, Robert Glidden, OU’s 19th president, quoted Alden, Ping and Harry Crewson, president from 1974-1975 in his speech, which centered on change both in the world and at the university level.
He described how OU should prepare students for change in all aspects of their lives and how professions increasingly demanded advanced skills and knowledge — which is why he believed university research was so crucial to the university and why he also hoped to address the needs of southeast Ohio and Athens.
“Universities address change in nearly everything we do,” Glidden said in his inaugural address.
The plans for each incoming OU president are no different.
Landing Page
This story is part of a series of specially designed stories that represents some of the best journalism The Post has to offer. Check out the rest of the special projects here.


Changeset 247
- Timestamp:
- 05/30/10 13:21:08 (6 years ago)
- Location:
- mystic/mystic
- Files:
-
- 2 edited
-
differential_evolution.py (modified) (4 diffs)
-
tools.py (modified) (2 diffs)
Legend:
- Unmodified
- Added
- Removed
-
mystic/mystic/differential_evolution.py
r242 r247 216 216 217 217 strategy -- the mutation strategy for generating new trial 218 solutions [default = Best1 Exp]218 solutions [default = Best1Bin] 219 219 CrossProbability -- the probability of cross-parameter mutations 220 [default = 0. 5]220 [default = 0.9] 221 221 ScalingFactor -- multiplier for the impact of mutations on the 222 trial solution [default = 0. 7]222 trial solution [default = 0.8] 223 223 callback -- an optional user-supplied function to call after each 224 224 iteration. It is called as callback(xk), where xk is … … 228 228 """ 229 229 #allow for inputs that don't conform to AbstractSolver interface 230 from mystic.strategy import Best1 Exp231 strategy=Best1 Exp#mutation strategy (see mystic.strategy)232 CrossProbability=0. 5#potential for parameter cross-mutation233 ScalingFactor=0. 7#multiplier for mutation impact230 from mystic.strategy import Best1Bin 231 strategy=Best1Bin #mutation strategy (see mystic.strategy) 232 CrossProbability=0.9 #potential for parameter cross-mutation 233 ScalingFactor=0.8 #multiplier for mutation impact 234 234 callback=None #user-supplied function, called after each step 235 235 disp=0 #non-zero to print convergence messages … … 400 400 401 401 strategy -- the mutation strategy for generating new trial 402 solutions [default = Best1 Exp]402 solutions [default = Best1Bin] 403 403 CrossProbability -- the probability of cross-parameter mutations 404 [default = 0. 5]404 [default = 0.9] 405 405 ScalingFactor -- multiplier for the impact of mutations on the 406 trial solution [default = 0. 7]406 trial solution [default = 0.8] 407 407 callback -- an optional user-supplied function to call after each 408 408 iteration. It is called as callback(xk), where xk is … … 416 416 """ 417 417 #allow for inputs that don't conform to AbstractSolver interface 418 from mystic.strategy import Best1 Exp419 strategy=Best1 Exp#mutation strategy (see mystic.strategy)420 CrossProbability=0. 5#potential for parameter cross-mutation421 ScalingFactor=0. 7#multiplier for mutation impact418 from mystic.strategy import Best1Bin 419 strategy=Best1Bin #mutation strategy (see mystic.strategy) 420 CrossProbability=0.9 #potential for parameter cross-mutation 421 ScalingFactor=0.8 #multiplier for mutation impact 422 422 callback=None #user-supplied function, called after each step 423 423 disp=0 #non-zero to print convergence messages -
mystic/mystic/tools.py
r245 r247 174 174 print "Generation %d has best Chi-Squared: %f" % (self._step, y) 175 175 if int(self._step % self._xinterval) == 0: 176 if isinstance(x,ndarray): x = list(x) 176 177 print "Generation %d has best fit parameters:\n %s" % (self._step, x) 177 178 self._step += 1 … … 210 211 x = x[0] #XXX: get the "best" fit... which should be in x[0] 211 212 if int(self._step % self._yinterval) == 0: 213 if isinstance(x,ndarray): x = list(x) 212 214 self._file.write(" %d %f %s\n" % (self._step, y, x)) 213 215 self._step += 1
Note: See TracChangeset
for help on using the changeset viewer.


device_unknown
On something else?
Contact:
Your Department Rep
On something else?
Contact:
Your Department Rep


{% autoescape off %}{{ b.msg }}{% endautoescape %}
{% endfor %}
{% else %}
No Posts To Display.
{% endif %}
Tools
Legal
Use or redistribution of the Boss system in source and/or binary forms, with or without modification, are permitted provided that the following conditions are met:
Redistributions of source code or binary forms must adhere to the terms and conditions of any applicable software licenses.
End-user documentation or notices, whether included as part of a redistribution or disseminated as part of a legal or scientific disclosure (e.g. publication) or advertisement, must include the following acknowledgement: The Boss software system was designed and developed by the Johns Hopkins University Applied Physics Laboratory (JHU/APL).
The names “The Boss”, “JHU/APL”, “Johns Hopkins University”, “Applied Physics Laboratory”, “MICrONS”, or “IARPA” must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact<EMAIL_ADDRESS>This source code and library is distributed in the hope that it will be useful, but is provided without any warranty of any kind.


-------------------------------------------------------------------------------- Lattice TRACE Report - Hold, Version Diamond (64-bit) <IP_ADDRESS>6 Mon Apr 06 16:34:58 2020 Copyright (c) 1991-1994 by NeoCAD Inc. All rights reserved. Copyright (c) 1995 AT&T Corp. All rights reserved. Copyright (c) 1995-2001 Lucent Technologies Inc. All rights reserved. Copyright (c) 2001 Agere Systems All rights reserved. Copyright (c) 2002-2019 Lattice Semiconductor Corporation, All rights reserved. Report Information ------------------ Design file: top Device,speed: LCMXO2-7000HE,M Report level: verbose report, limited to 10 items per preference -------------------------------------------------------------------------------- ================================================================================ Preference: FREQUENCY NET "osc_clk" 88.670000 MHz ; 10 items scored, 0 timing errors detected. -------------------------------------------------------------------------------- Passed: The following path meets requirements by 0.303ns Logical Details: Cell type Pin type Cell/ASIC name (clock net +/-) Source: FF Q CIC1Sin/v_comb_66 (from osc_clk +) Destination: FF Data in CIC1Sin/d_out_i0_i7 (to osc_clk +) FF CIC1Sin/d_out_i0_i6 Delay: 0.279ns (47.7% logic, 52.3% route), 1 logic levels. Constraint Details: 0.279ns physical path delay CIC1Sin/SLICE_2186 to CIC1Sin/SLICE_2220 meets -0.024ns CE_HLD and 0.000ns delay constraint less 0.000ns skew requirement (totaling -0.024ns) by 0.303ns Physical Path Details: Data path CIC1Sin/SLICE_2186 to CIC1Sin/SLICE_2220: Name Fanout Delay (ns) Site Resource REG_DEL --- 0.133 R9C23B.CLK to R9C23B.Q0 CIC1Sin/SLICE_2186 (from osc_clk) ROUTE 17 0.146 R9C23B.Q0 to R9C23D.CE CIC1Sin/v_comb (to osc_clk) -------- 0.279 (47.7% logic, 52.3% route), 1 logic levels. Clock Skew Details: Source Clock Path OSCH_inst to CIC1Sin/SLICE_2186: Name Fanout Delay (ns) Site Resource ROUTE 999 1.443 OSC.OSC to R9C23B.CLK osc_clk -------- 1.443 (0.0% logic, 100.0% route), 0 logic levels. Destination Clock Path OSCH_inst to CIC1Sin/SLICE_2220: Name Fanout Delay (ns) Site Resource ROUTE 999 1.443 OSC.OSC to R9C23D.CLK osc_clk -------- 1.443 (0.0% logic, 100.0% route), 0 logic levels. Passed: The following path meets requirements by 0.304ns Logical Details: Cell type Pin type Cell/ASIC name (clock net +/-) Source: FF Q CIC1Cos/v_comb_66 (from osc_clk +) Destination: FF Data in CIC1Cos/d_out_i0_i9 (to osc_clk +) FF CIC1Cos/d_out_i0_i8 Delay: 0.280ns (47.5% logic, 52.5% route), 1 logic levels. Constraint Details: 0.280ns physical path delay CIC1Cos/SLICE_1935 to SLICE_2192 meets -0.024ns CE_HLD and 0.000ns delay constraint less 0.000ns skew requirement (totaling -0.024ns) by 0.304ns Physical Path Details: Data path CIC1Cos/SLICE_1935 to SLICE_2192: Name Fanout Delay (ns) Site Resource REG_DEL --- 0.133 R9C25B.CLK to R9C25B.Q0 CIC1Cos/SLICE_1935 (from osc_clk) ROUTE 15 0.147 R9C25B.Q0 to R9C25D.CE CIC1Cos/v_comb (to osc_clk) -------- 0.280 (47.5% logic, 52.5% route), 1 logic levels. Clock Skew Details: Source Clock Path OSCH_inst to CIC1Cos/SLICE_1935: Name Fanout Delay (ns) Site Resource ROUTE 999 1.443 OSC.OSC to R9C25B.CLK osc_clk -------- 1.443 (0.0% logic, 100.0% route), 0 logic levels. Destination Clock Path OSCH_inst to SLICE_2192: Name Fanout Delay (ns) Site Resource ROUTE 999 1.443 OSC.OSC to R9C25D.CLK osc_clk -------- 1.443 (0.0% logic, 100.0% route), 0 logic levels. Passed: The following path meets requirements by 0.306ns Logical Details: Cell type Pin type Cell/ASIC name (clock net +/-) Source: FF Q Mixer1/RFInR1_13 (from osc_clk +) Destination: FF Data in Mixer1/RFInR_14 (to osc_clk +) Delay: 0.287ns (46.3% logic, 53.7% route), 1 logic levels. Constraint Details: 0.287ns physical path delay Mixer1/SLICE_2225 to Mixer1/SLICE_2225 meets -0.019ns M_HLD and 0.000ns delay constraint less 0.000ns skew requirement (totaling -0.019ns) by 0.306ns Physical Path Details: Data path Mixer1/SLICE_2225 to Mixer1/SLICE_2225: Name Fanout Delay (ns) Site Resource REG_DEL --- 0.133 R2C19A.CLK to R2C19A.Q1 Mixer1/SLICE_2225 (from osc_clk) ROUTE 2 0.154 R2C19A.Q1 to R2C19A.M0 DiffOut_c (to osc_clk) -------- 0.287 (46.3% logic, 53.7% route), 1 logic levels. Clock Skew Details: Source Clock Path OSCH_inst to Mixer1/SLICE_2225: Name Fanout Delay (ns) Site Resource ROUTE 999 1.443 OSC.OSC to R2C19A.CLK osc_clk -------- 1.443 (0.0% logic, 100.0% route), 0 logic levels. Destination Clock Path OSCH_inst to Mixer1/SLICE_2225: Name Fanout Delay (ns) Site Resource ROUTE 999 1.443 OSC.OSC to R2C19A.CLK osc_clk -------- 1.443 (0.0% logic, 100.0% route), 0 logic levels. Passed: The following path meets requirements by 0.306ns Logical Details: Cell type Pin type Cell/ASIC name (clock net +/-) Source: FF Q CIC1Cos/d6_i0_i33 (from osc_clk +) Destination: FF Data in CIC1Cos/d_d6_i0_i33 (to osc_clk +) Delay: 0.287ns (46.3% logic, 53.7% route), 1 logic levels. Constraint Details: 0.287ns physical path delay CIC1Cos/SLICE_1588 to CIC1Cos/SLICE_1724 meets -0.019ns M_HLD and 0.000ns delay constraint less 0.000ns skew requirement (totaling -0.019ns) by 0.306ns Physical Path Details: Data path CIC1Cos/SLICE_1588 to CIC1Cos/SLICE_1724: Name Fanout Delay (ns) Site Resource REG_DEL --- 0.133 R22C39B.CLK to R22C39B.Q0 CIC1Cos/SLICE_1588 (from osc_clk) ROUTE 2 0.154 R22C39B.Q0 to R22C39D.M0 CIC1Cos/d6_33 (to osc_clk) -------- 0.287 (46.3% logic, 53.7% route), 1 logic levels. Clock Skew Details: Source Clock Path OSCH_inst to CIC1Cos/SLICE_1588: Name Fanout Delay (ns) Site Resource ROUTE 999 1.425 OSC.OSC to R22C39B.CLK osc_clk -------- 1.425 (0.0% logic, 100.0% route), 0 logic levels. Destination Clock Path OSCH_inst to CIC1Cos/SLICE_1724: Name Fanout Delay (ns) Site Resource ROUTE 999 1.425 OSC.OSC to R22C39D.CLK osc_clk -------- 1.425 (0.0% logic, 100.0% route), 0 logic levels. Passed: The following path meets requirements by 0.306ns Logical Details: Cell type Pin type Cell/ASIC name (clock net +/-) Source: FF Q CIC1Cos/d6_i0_i34 (from osc_clk +) Destination: FF Data in CIC1Cos/d_d6_i0_i34 (to osc_clk +) Delay: 0.287ns (46.3% logic, 53.7% route), 1 logic levels. Constraint Details: 0.287ns physical path delay CIC1Cos/SLICE_1588 to CIC1Cos/SLICE_1724 meets -0.019ns M_HLD and 0.000ns delay constraint less 0.000ns skew requirement (totaling -0.019ns) by 0.306ns Physical Path Details: Data path CIC1Cos/SLICE_1588 to CIC1Cos/SLICE_1724: Name Fanout Delay (ns) Site Resource REG_DEL --- 0.133 R22C39B.CLK to R22C39B.Q1 CIC1Cos/SLICE_1588 (from osc_clk) ROUTE 2 0.154 R22C39B.Q1 to R22C39D.M1 CIC1Cos/d6_34 (to osc_clk) -------- 0.287 (46.3% logic, 53.7% route), 1 logic levels. Clock Skew Details: Source Clock Path OSCH_inst to CIC1Cos/SLICE_1588: Name Fanout Delay (ns) Site Resource ROUTE 999 1.425 OSC.OSC to R22C39B.CLK osc_clk -------- 1.425 (0.0% logic, 100.0% route), 0 logic levels. Destination Clock Path OSCH_inst to CIC1Cos/SLICE_1724: Name Fanout Delay (ns) Site Resource ROUTE 999 1.425 OSC.OSC to R22C39D.CLK osc_clk -------- 1.425 (0.0% logic, 100.0% route), 0 logic levels. Passed: The following path meets requirements by 0.306ns Logical Details: Cell type Pin type Cell/ASIC name (clock net +/-) Source: FF Q CIC1Cos/d_tmp_i0_i2 (from osc_clk +) Destination: FF Data in CIC1Cos/d_d_tmp_i0_i2 (to osc_clk +) Delay: 0.287ns (46.3% logic, 53.7% route), 1 logic levels. Constraint Details: 0.287ns physical path delay CIC1Cos/SLICE_1893 to CIC1Cos/SLICE_1856 meets -0.019ns M_HLD and 0.000ns delay constraint less 0.000ns skew requirement (totaling -0.019ns) by 0.306ns Physical Path Details: Data path CIC1Cos/SLICE_1893 to CIC1Cos/SLICE_1856: Name Fanout Delay (ns) Site Resource REG_DEL --- 0.133 R23C35A.CLK to R23C35A.Q0 CIC1Cos/SLICE_1893 (from osc_clk) ROUTE 2 0.154 R23C35A.Q0 to R23C35D.M0 CIC1Cos/d_tmp_2 (to osc_clk) -------- 0.287 (46.3% logic, 53.7% route), 1 logic levels. Clock Skew Details: Source Clock Path OSCH_inst to CIC1Cos/SLICE_1893: Name Fanout Delay (ns) Site Resource ROUTE 999 1.425 OSC.OSC to R23C35A.CLK osc_clk -------- 1.425 (0.0% logic, 100.0% route), 0 logic levels. Destination Clock Path OSCH_inst to CIC1Cos/SLICE_1856: Name Fanout Delay (ns) Site Resource ROUTE 999 1.425 OSC.OSC to R23C35D.CLK osc_clk -------- 1.425 (0.0% logic, 100.0% route), 0 logic levels. Passed: The following path meets requirements by 0.306ns Logical Details: Cell type Pin type Cell/ASIC name (clock net +/-) Source: FF Q CIC1Cos/d_tmp_i0_i3 (from osc_clk +) Destination: FF Data in CIC1Cos/d_d_tmp_i0_i3 (to osc_clk +) Delay: 0.287ns (46.3% logic, 53.7% route), 1 logic levels. Constraint Details: 0.287ns physical path delay CIC1Cos/SLICE_1893 to CIC1Cos/SLICE_1856 meets -0.019ns M_HLD and 0.000ns delay constraint less 0.000ns skew requirement (totaling -0.019ns) by 0.306ns Physical Path Details: Data path CIC1Cos/SLICE_1893 to CIC1Cos/SLICE_1856: Name Fanout Delay (ns) Site Resource REG_DEL --- 0.133 R23C35A.CLK to R23C35A.Q1 CIC1Cos/SLICE_1893 (from osc_clk) ROUTE 2 0.154 R23C35A.Q1 to R23C35D.M1 CIC1Cos/d_tmp_3 (to osc_clk) -------- 0.287 (46.3% logic, 53.7% route), 1 logic levels. Clock Skew Details: Source Clock Path OSCH_inst to CIC1Cos/SLICE_1893: Name Fanout Delay (ns) Site Resource ROUTE 999 1.425 OSC.OSC to R23C35A.CLK osc_clk -------- 1.425 (0.0% logic, 100.0% route), 0 logic levels. Destination Clock Path OSCH_inst to CIC1Cos/SLICE_1856: Name Fanout Delay (ns) Site Resource ROUTE 999 1.425 OSC.OSC to R23C35D.CLK osc_clk -------- 1.425 (0.0% logic, 100.0% route), 0 logic levels. Passed: The following path meets requirements by 0.307ns Logical Details: Cell type Pin type Cell/ASIC name (clock net +/-) Source: FF Q CIC1Cos/d5_i67 (from osc_clk +) Destination: FF Data in CIC1Cos/d_tmp_i0_i67 (to osc_clk +) Delay: 0.288ns (46.2% logic, 53.8% route), 1 logic levels. Constraint Details: 0.288ns physical path delay CIC1Cos/SLICE_1108 to CIC1Cos/SLICE_1925 meets -0.019ns M_HLD and 0.000ns delay constraint less 0.000ns skew requirement (totaling -0.019ns) by 0.307ns Physical Path Details: Data path CIC1Cos/SLICE_1108 to CIC1Cos/SLICE_1925: Name Fanout Delay (ns) Site Resource REG_DEL --- 0.133 R15C31A.CLK to R15C31A.Q1 CIC1Cos/SLICE_1108 (from osc_clk) ROUTE 3 0.155 R15C31A.Q1 to R15C31D.M1 CIC1Cos/d5_67 (to osc_clk) -------- 0.288 (46.2% logic, 53.8% route), 1 logic levels. Clock Skew Details: Source Clock Path OSCH_inst to CIC1Cos/SLICE_1108: Name Fanout Delay (ns) Site Resource ROUTE 999 1.443 OSC.OSC to R15C31A.CLK osc_clk -------- 1.443 (0.0% logic, 100.0% route), 0 logic levels. Destination Clock Path OSCH_inst to CIC1Cos/SLICE_1925: Name Fanout Delay (ns) Site Resource ROUTE 999 1.443 OSC.OSC to R15C31D.CLK osc_clk -------- 1.443 (0.0% logic, 100.0% route), 0 logic levels. Passed: The following path meets requirements by 0.307ns Logical Details: Cell type Pin type Cell/ASIC name (clock net +/-) Source: FF Q SinCos1/FF_55 (from osc_clk +) Destination: FF Data in SinCos1/FF_27 (to osc_clk +) Delay: 0.288ns (46.2% logic, 53.8% route), 1 logic levels. Constraint Details: 0.288ns physical path delay SinCos1/SLICE_2275 to SinCos1/SLICE_2275 meets -0.019ns M_HLD and 0.000ns delay constraint less 0.000ns skew requirement (totaling -0.019ns) by 0.307ns Physical Path Details: Data path SinCos1/SLICE_2275 to SinCos1/SLICE_2275: Name Fanout Delay (ns) Site Resource REG_DEL --- 0.133 R9C4B.CLK to R9C4B.Q1 SinCos1/SLICE_2275 (from osc_clk) ROUTE 3 0.155 R9C4B.Q1 to R9C4B.M0 SinCos1/mx_ctrl_r_1 (to osc_clk) -------- 0.288 (46.2% logic, 53.8% route), 1 logic levels. Clock Skew Details: Source Clock Path OSCH_inst to SinCos1/SLICE_2275: Name Fanout Delay (ns) Site Resource ROUTE 999 1.443 OSC.OSC to R9C4B.CLK osc_clk -------- 1.443 (0.0% logic, 100.0% route), 0 logic levels. Destination Clock Path OSCH_inst to SinCos1/SLICE_2275: Name Fanout Delay (ns) Site Resource ROUTE 999 1.443 OSC.OSC to R9C4B.CLK osc_clk -------- 1.443 (0.0% logic, 100.0% route), 0 logic levels. Passed: The following path meets requirements by 0.307ns Logical Details: Cell type Pin type Cell/ASIC name (clock net +/-) Source: FF Q CIC1Cos/d5_i66 (from osc_clk +) Destination: FF Data in CIC1Cos/d_tmp_i0_i66 (to osc_clk +) Delay: 0.288ns (46.2% logic, 53.8% route), 1 logic levels. Constraint Details: 0.288ns physical path delay CIC1Cos/SLICE_1108 to CIC1Cos/SLICE_1925 meets -0.019ns M_HLD and 0.000ns delay constraint less 0.000ns skew requirement (totaling -0.019ns) by 0.307ns Physical Path Details: Data path CIC1Cos/SLICE_1108 to CIC1Cos/SLICE_1925: Name Fanout Delay (ns) Site Resource REG_DEL --- 0.133 R15C31A.CLK to R15C31A.Q0 CIC1Cos/SLICE_1108 (from osc_clk) ROUTE 3 0.155 R15C31A.Q0 to R15C31D.M0 CIC1Cos/d5_66 (to osc_clk) -------- 0.288 (46.2% logic, 53.8% route), 1 logic levels. Clock Skew Details: Source Clock Path OSCH_inst to CIC1Cos/SLICE_1108: Name Fanout Delay (ns) Site Resource ROUTE 999 1.443 OSC.OSC to R15C31A.CLK osc_clk -------- 1.443 (0.0% logic, 100.0% route), 0 logic levels. Destination Clock Path OSCH_inst to CIC1Cos/SLICE_1925: Name Fanout Delay (ns) Site Resource ROUTE 999 1.443 OSC.OSC to R15C31D.CLK osc_clk -------- 1.443 (0.0% logic, 100.0% route), 0 logic levels. ================================================================================ Preference: CLOCK_TO_OUT ALLPORTS 20.000000 ns CLKNET "osc_clk" ; 10 items scored, 0 timing errors detected. -------------------------------------------------------------------------------- Passed: The following path meets requirements by 2.857ns Logical Details: Cell type Pin type Cell/ASIC name (clock net +/-) Source: FF Q Mixer1/RFInR1_13 (from osc_clk +) Destination: Port Pad DiffOut Data Path Delay: 1.666ns (73.0% logic, 27.0% route), 2 logic levels. Clock Path Delay: 1.191ns (0.0% logic, 100.0% route), 0 logic levels. Constraint Details: 1.191ns delay OSCH_inst to Mixer1/SLICE_2225 and 1.666ns delay Mixer1/SLICE_2225 to DiffOut (totaling 2.857ns) meets 0.000ns hold offset OSCH_inst to DiffOut by 2.857ns Physical Path Details: Clock path OSCH_inst to Mixer1/SLICE_2225: Name Fanout Delay (ns) Site Resource ROUTE 999 1.191 OSC.OSC to R2C19A.CLK osc_clk -------- 1.191 (0.0% logic, 100.0% route), 0 logic levels. Data path Mixer1/SLICE_2225 to DiffOut: Name Fanout Delay (ns) Site Resource REG_DEL --- 0.133 R2C19A.CLK to R2C19A.Q1 Mixer1/SLICE_2225 (from osc_clk) ROUTE 2 0.449 R2C19A.Q1 to 122.PADDO DiffOut_c DOPAD_DEL --- 1.084 122.PADDO to 122.PAD DiffOut -------- 1.666 (73.0% logic, 27.0% route), 2 logic levels. Passed: The following path meets requirements by 2.875ns Logical Details: Cell type Pin type Cell/ASIC name (clock net +/-) Source: FF Q CIC1Sin/d_out_i0_i6 (from osc_clk +) Destination: Port Pad MYLED[0] Data Path Delay: 1.684ns (64.5% logic, 35.5% route), 2 logic levels. Clock Path Delay: 1.191ns (0.0% logic, 100.0% route), 0 logic levels. Constraint Details: 1.191ns delay OSCH_inst to CIC1Sin/SLICE_2220 and 1.684ns delay CIC1Sin/SLICE_2220 to MYLED[0] (totaling 2.875ns) meets 0.000ns hold offset OSCH_inst to MYLED[0] by 2.875ns Physical Path Details: Clock path OSCH_inst to CIC1Sin/SLICE_2220: Name Fanout Delay (ns) Site Resource ROUTE 999 1.191 OSC.OSC to R9C23D.CLK osc_clk -------- 1.191 (0.0% logic, 100.0% route), 0 logic levels. Data path CIC1Sin/SLICE_2220 to MYLED[0]: Name Fanout Delay (ns) Site Resource REG_DEL --- 0.133 R9C23D.CLK to R9C23D.Q0 CIC1Sin/SLICE_2220 (from osc_clk) ROUTE 2 0.598 R9C23D.Q0 to 97.PADDO MYLED_c_0 DOPAD_DEL --- 0.953 97.PADDO to 97.PAD MYLED[0] -------- 1.684 (64.5% logic, 35.5% route), 2 logic levels. Passed: The following path meets requirements by 3.016ns Logical Details: Cell type Pin type Cell/ASIC name (clock net +/-) Source: FF Q CIC1Sin/d_out_i0_i11 (from osc_clk +) Destination: Port Pad MYLED[5] Data Path Delay: 1.825ns (59.5% logic, 40.5% route), 2 logic levels. Clock Path Delay: 1.191ns (0.0% logic, 100.0% route), 0 logic levels. Constraint Details: 1.191ns delay OSCH_inst to CIC1Sin/SLICE_2223 and 1.825ns delay CIC1Sin/SLICE_2223 to MYLED[5] (totaling 3.016ns) meets 0.000ns hold offset OSCH_inst to MYLED[5] by 3.016ns Physical Path Details: Clock path OSCH_inst to CIC1Sin/SLICE_2223: Name Fanout Delay (ns) Site Resource ROUTE 999 1.191 OSC.OSC to R9C22D.CLK osc_clk -------- 1.191 (0.0% logic, 100.0% route), 0 logic levels. Data path CIC1Sin/SLICE_2223 to MYLED[5]: Name Fanout Delay (ns) Site Resource REG_DEL --- 0.133 R9C22D.CLK to R9C22D.Q0 CIC1Sin/SLICE_2223 (from osc_clk) ROUTE 2 0.739 R9C22D.Q0 to 105.PADDO MYLED_c_5 DOPAD_DEL --- 0.953 105.PADDO to 105.PAD MYLED[5] -------- 1.825 (59.5% logic, 40.5% route), 2 logic levels. Passed: The following path meets requirements by 3.158ns Logical Details: Cell type Pin type Cell/ASIC name (clock net +/-) Source: FF Q CIC1Sin/d_out_i0_i7 (from osc_clk +) Destination: Port Pad MYLED[1] Data Path Delay: 1.967ns (55.2% logic, 44.8% route), 2 logic levels. Clock Path Delay: 1.191ns (0.0% logic, 100.0% route), 0 logic levels. Constraint Details: 1.191ns delay OSCH_inst to CIC1Sin/SLICE_2220 and 1.967ns delay CIC1Sin/SLICE_2220 to MYLED[1] (totaling 3.158ns) meets 0.000ns hold offset OSCH_inst to MYLED[1] by 3.158ns Physical Path Details: Clock path OSCH_inst to CIC1Sin/SLICE_2220: Name Fanout Delay (ns) Site Resource ROUTE 999 1.191 OSC.OSC to R9C23D.CLK osc_clk -------- 1.191 (0.0% logic, 100.0% route), 0 logic levels. Data path CIC1Sin/SLICE_2220 to MYLED[1]: Name Fanout Delay (ns) Site Resource REG_DEL --- 0.133 R9C23D.CLK to R9C23D.Q1 CIC1Sin/SLICE_2220 (from osc_clk) ROUTE 2 0.881 R9C23D.Q1 to 98.PADDO MYLED_c_1 DOPAD_DEL --- 0.953 98.PADDO to 98.PAD MYLED[1] -------- 1.967 (55.2% logic, 44.8% route), 2 logic levels. Passed: The following path meets requirements by 3.261ns Logical Details: Cell type Pin type Cell/ASIC name (clock net +/-) Source: FF Q CIC1Sin/d_out_i0_i9 (from osc_clk +) Destination: Port Pad MYLED[3] Data Path Delay: 2.070ns (52.5% logic, 47.5% route), 2 logic levels. Clock Path Delay: 1.191ns (0.0% logic, 100.0% route), 0 logic levels. Constraint Details: 1.191ns delay OSCH_inst to CIC1Sin/SLICE_2221 and 2.070ns delay CIC1Sin/SLICE_2221 to MYLED[3] (totaling 3.261ns) meets 0.000ns hold offset OSCH_inst to MYLED[3] by 3.261ns Physical Path Details: Clock path OSCH_inst to CIC1Sin/SLICE_2221: Name Fanout Delay (ns) Site Resource ROUTE 999 1.191 OSC.OSC to R9C22B.CLK osc_clk -------- 1.191 (0.0% logic, 100.0% route), 0 logic levels. Data path CIC1Sin/SLICE_2221 to MYLED[3]: Name Fanout Delay (ns) Site Resource REG_DEL --- 0.133 R9C22B.CLK to R9C22B.Q1 CIC1Sin/SLICE_2221 (from osc_clk) ROUTE 2 0.984 R9C22B.Q1 to 100.PADDO MYLED_c_3 DOPAD_DEL --- 0.953 100.PADDO to 100.PAD MYLED[3] -------- 2.070 (52.5% logic, 47.5% route), 2 logic levels. Passed: The following path meets requirements by 3.289ns Logical Details: Cell type Pin type Cell/ASIC name (clock net +/-) Source: FF Q CIC1Sin/d_out_i0_i8 (from osc_clk +) Destination: Port Pad MYLED[2] Data Path Delay: 2.098ns (51.8% logic, 48.2% route), 2 logic levels. Clock Path Delay: 1.191ns (0.0% logic, 100.0% route), 0 logic levels. Constraint Details: 1.191ns delay OSCH_inst to CIC1Sin/SLICE_2221 and 2.098ns delay CIC1Sin/SLICE_2221 to MYLED[2] (totaling 3.289ns) meets 0.000ns hold offset OSCH_inst to MYLED[2] by 3.289ns Physical Path Details: Clock path OSCH_inst to CIC1Sin/SLICE_2221: Name Fanout Delay (ns) Site Resource ROUTE 999 1.191 OSC.OSC to R9C22B.CLK osc_clk -------- 1.191 (0.0% logic, 100.0% route), 0 logic levels. Data path CIC1Sin/SLICE_2221 to MYLED[2]: Name Fanout Delay (ns) Site Resource REG_DEL --- 0.133 R9C22B.CLK to R9C22B.Q0 CIC1Sin/SLICE_2221 (from osc_clk) ROUTE 2 1.012 R9C22B.Q0 to 99.PADDO MYLED_c_2 DOPAD_DEL --- 0.953 99.PADDO to 99.PAD MYLED[2] -------- 2.098 (51.8% logic, 48.2% route), 2 logic levels. Passed: The following path meets requirements by 3.495ns Logical Details: Cell type Pin type Cell/ASIC name (clock net +/-) Source: FF Q PWM1/PWMOut_15 (from osc_clk +) Destination: Port Pad PWMOutP3 Data Path Delay: 2.304ns (52.8% logic, 47.2% route), 2 logic levels. Clock Path Delay: 1.191ns (0.0% logic, 100.0% route), 0 logic levels. Constraint Details: 1.191ns delay OSCH_inst to PWM1/SLICE_6 and 2.304ns delay PWM1/SLICE_6 to PWMOutP3 (totaling 3.495ns) meets 0.000ns hold offset OSCH_inst to PWMOutP3 by 3.495ns Physical Path Details: Clock path OSCH_inst to PWM1/SLICE_6: Name Fanout Delay (ns) Site Resource ROUTE 999 1.191 OSC.OSC to R12C25B.CLK osc_clk -------- 1.191 (0.0% logic, 100.0% route), 0 logic levels. Data path PWM1/SLICE_6 to PWMOutP3: Name Fanout Delay (ns) Site Resource REG_DEL --- 0.133 R12C25B.CLK to R12C25B.Q1 PWM1/SLICE_6 (from osc_clk) ROUTE 6 1.087 R12C25B.Q1 to 68.PADDO PWMOutP4_c DOPAD_DEL --- 1.084 68.PADDO to 68.PAD PWMOutP3 -------- 2.304 (52.8% logic, 47.2% route), 2 logic levels. Passed: The following path meets requirements by 3.495ns Logical Details: Cell type Pin type Cell/ASIC name (clock net +/-) Source: FF Q PWM1/PWMOut_15 (from osc_clk +) Destination: Port Pad PWMOutP4 Data Path Delay: 2.304ns (52.8% logic, 47.2% route), 2 logic levels. Clock Path Delay: 1.191ns (0.0% logic, 100.0% route), 0 logic levels. Constraint Details: 1.191ns delay OSCH_inst to PWM1/SLICE_6 and 2.304ns delay PWM1/SLICE_6 to PWMOutP4 (totaling 3.495ns) meets 0.000ns hold offset OSCH_inst to PWMOutP4 by 3.495ns Physical Path Details: Clock path OSCH_inst to PWM1/SLICE_6: Name Fanout Delay (ns) Site Resource ROUTE 999 1.191 OSC.OSC to R12C25B.CLK osc_clk -------- 1.191 (0.0% logic, 100.0% route), 0 logic levels. Data path PWM1/SLICE_6 to PWMOutP4: Name Fanout Delay (ns) Site Resource REG_DEL --- 0.133 R12C25B.CLK to R12C25B.Q1 PWM1/SLICE_6 (from osc_clk) ROUTE 6 1.087 R12C25B.Q1 to 69.PADDO PWMOutP4_c DOPAD_DEL --- 1.084 69.PADDO to 69.PAD PWMOutP4 -------- 2.304 (52.8% logic, 47.2% route), 2 logic levels. Passed: The following path meets requirements by 3.510ns Logical Details: Cell type Pin type Cell/ASIC name (clock net +/-) Source: FF Q PWM1/PWMOut_15 (from osc_clk +) Destination: Port Pad PWMOutN3 Data Path Delay: 2.319ns (56.8% logic, 43.2% route), 3 logic levels. Clock Path Delay: 1.191ns (0.0% logic, 100.0% route), 0 logic levels. Constraint Details: 1.191ns delay OSCH_inst to PWM1/SLICE_6 and 2.319ns delay PWM1/SLICE_6 to PWMOutN3 (totaling 3.510ns) meets 0.000ns hold offset OSCH_inst to PWMOutN3 by 3.510ns Physical Path Details: Clock path OSCH_inst to PWM1/SLICE_6: Name Fanout Delay (ns) Site Resource ROUTE 999 1.191 OSC.OSC to R12C25B.CLK osc_clk -------- 1.191 (0.0% logic, 100.0% route), 0 logic levels. Data path PWM1/SLICE_6 to PWMOutN3: Name Fanout Delay (ns) Site Resource REG_DEL --- 0.133 R12C25B.CLK to R12C25B.Q1 PWM1/SLICE_6 (from osc_clk) ROUTE 6 0.818 R12C25B.Q1 to R25C38B.C0 PWMOutP4_c CTOF_DEL --- 0.101 R25C38B.C0 to R25C38B.F0 SLICE_2495 ROUTE 4 0.183 R25C38B.F0 to 70.PADDO PWMOutN4_c DOPAD_DEL --- 1.084 70.PADDO to 70.PAD PWMOutN3 -------- 2.319 (56.8% logic, 43.2% route), 3 logic levels. Passed: The following path meets requirements by 3.510ns Logical Details: Cell type Pin type Cell/ASIC name (clock net +/-) Source: FF Q PWM1/PWMOut_15 (from osc_clk +) Destination: Port Pad PWMOutN4 Data Path Delay: 2.319ns (56.8% logic, 43.2% route), 3 logic levels. Clock Path Delay: 1.191ns (0.0% logic, 100.0% route), 0 logic levels. Constraint Details: 1.191ns delay OSCH_inst to PWM1/SLICE_6 and 2.319ns delay PWM1/SLICE_6 to PWMOutN4 (totaling 3.510ns) meets 0.000ns hold offset OSCH_inst to PWMOutN4 by 3.510ns Physical Path Details: Clock path OSCH_inst to PWM1/SLICE_6: Name Fanout Delay (ns) Site Resource ROUTE 999 1.191 OSC.OSC to R12C25B.CLK osc_clk -------- 1.191 (0.0% logic, 100.0% route), 0 logic levels. Data path PWM1/SLICE_6 to PWMOutN4: Name Fanout Delay (ns) Site Resource REG_DEL --- 0.133 R12C25B.CLK to R12C25B.Q1 PWM1/SLICE_6 (from osc_clk) ROUTE 6 0.818 R12C25B.Q1 to R25C38B.C0 PWMOutP4_c CTOF_DEL --- 0.101 R25C38B.C0 to R25C38B.F0 SLICE_2495 ROUTE 4 0.183 R25C38B.F0 to 71.PADDO PWMOutN4_c DOPAD_DEL --- 1.084 71.PADDO to 71.PAD PWMOutN4 -------- 2.319 (56.8% logic, 43.2% route), 3 logic levels. Report: 2.857ns is the maximum offset for this preference. Report Summary -------------- ---------------------------------------------------------------------------- Preference(MIN Delays) | Constraint| Actual|Levels ---------------------------------------------------------------------------- | | | FREQUENCY NET "osc_clk" 88.670000 MHz ; | 0.000 ns| 0.303 ns| 1 | | | CLOCK_TO_OUT ALLPORTS 20.000000 ns | | | CLKNET "osc_clk" ; | 0.000 ns| 2.857 ns| 2 | | | ---------------------------------------------------------------------------- All preferences were met. Clock Domains Analysis ------------------------ Found 3 clocks: Clock Domain: uart_rx1/UartClk[2] Source: uart_rx1/SLICE_12.Q1 Loads: 29 No transfer within this clock domain is found Clock Domain: osc_clk Source: OSCH_inst.OSC Loads: 1369 Covered under: FREQUENCY NET "osc_clk" 88.670000 MHz ; Data transfers from: Clock Domain: uart_rx1/UartClk[2] Source: uart_rx1/SLICE_12.Q1 Covered under: FREQUENCY NET "osc_clk" 88.670000 MHz ; Transfers: 9 Clock Domain: CIC1_out_clkSin Source: CIC1Sin/SLICE_2199.Q0 Covered under: FREQUENCY NET "osc_clk" 88.670000 MHz ; Transfers: 10 Clock Domain: CIC1_out_clkSin Source: CIC1Sin/SLICE_2199.Q0 Loads: 153 No transfer within this clock domain is found Timing summary (Hold): --------------- Timing errors: 0 Score: 0 Cumulative negative slack: 0 Constraints cover 1466856 paths, 1 nets, and 16495 connections (99.99% coverage) Timing summary (Setup and Hold): --------------- Timing errors: 10 (setup), 0 (hold) Score: 37626 (setup), 0 (hold) Cumulative negative slack: 37626 (37626+0)


It is probably in your inbox already. If its not you can send another email with the button below.
snaptasq is a friends only service. We will only show tasks posted by friends. This is done by connecting with your Facebook.
We don't want to post anything on your Facebook wall. snaptasq has its own wall.
For more information please view our privacy policy here
snaptasq was unable to find your friends from Facebook. This can happen when you change Facebook settings. To fix this, click connect with facebook
We don't want to post anything on your Facebook wall. snaptasq has its own wall.
For more information please view our privacy policy here


Always a pleasure developping a Web App.
Yeoman is a professional generator for building fast, robust, and adaptable web apps or sites.
Bootstrap is a professional front-end template Bootstrap components
AngularJS is a toolset for building the framework most suited to your application development.
Spectacular Test Runner for JavaScript.


[gecode-users] vector or PrimArgArray ?
Vincent Barichard
Vincent.Barichard at univ-angers.fr
Fri Jan 22 22:20:56 CET 2010
Hi,
I made a subclass of Brancher in order to implement my own behaviour (class QViewBrancher : public Brancher).
I copied the code of ViewBrancher and modified it to make it match with my needs. In this new class, I
added another variable member which is an array of integers.
So I added a new member "const std::vector<int> q;" in QViewBrancher. But now I wonder if I had to use a
PrimArgArray<int> or IntArgs instead of vector ,
What do you think about it ? Vector or PrimArgArray ? (The size of the vector is equal to the size of the ViewArray x)
Thank you very much for your advise.
Cheers,
Vincent
Vincent Barichard Université d'Angers (LERIA)
Tel: 02 41 73 52 06 Département Informatique
Fax: 02 41 73 50 73 H203
More information about the users
mailing list


Extreme career fair draws hundreds to Langley Events Centre
Black Press event included more than 60 employers
There were no shortage of job opportunities or prospective employees at the Black Press Extreme Education and Career Fair Thursday afternoon.
The biggest challenge for some of the job seekers seemed to be elbowing their way to the front line at some 62 job booths at the Langley Events Centre from 11 a.m. to 3 p.m.
The event, held several times per year throughout the province and Alberta, included participation from several universities, a plethora of industries in the medical field, enforcement and rescue services and high-tech companies.
Air Canada representative Sara Montalvan, who flew in from Montreal, said the company spent Thursday’s effort focusing on attracting more ramp agents.
A ramp agent is primarily responsible for handling aircraft baggage, as well as loading and unloading luggage onto the airplane and guiding aircraft to and from the gates.
“It’s very physical but it’s very fast paced,” Montalvan said. “We thought this was a great event to attract more people to work for us.”
Lafarge operations manager Mike Darby was also looking for potential employees that don’t mind getting their hands dirty.
Lafarge is an industrial company specializing in cement, construction aggregates, and concrete.
“We’re looking for some construction workers, guys that are motivated and ready to work outside throughout the year. The winter time is slower for us but we’re looking for guys that are motivated,” Darby said.
He said the company is looking to hire people with a “good attitude.”
“A guy that’s not going to stand around. He’s going to look for something to do all of the time, asking questions and willingness to learn. That’s the most important, it’s that attitude we’re looking for.”
To learn when and where the next career fair will be, or to view active job postings throughout the province, check out the Black Press Extreme Education & Career Fair Facebook page.