Actually spent: 9 hours

Actual time spent: 3 hours

A Stranger in a Strange Land

Monday morning I flew out of Austin headed to Paris by way of Charlotte, North Carolina. Thirteen hours later I arrived in Paris, for the first time alone in a foreign country where I did not speak the language at all. I had been to Germany, but I know German, rusty though it may be. I was also with my father and had a German missionary for a guide. This was different.

I found myself very quiet, subconsciously hoping that if I did not speak, people would not notice that I did not fit in. There is also that whole pride issue: I did not want to appear ignorant of my surroundings, but of course, I knew nothing of Paris, Charles de Gaulle Airport, or the subway system.

I think everyone should spend some time as the ignorant foreigner. It would do wonders for our humility and just maybe help us have more active compassion for others.

I had four tasks for myself before getting out of the airport:

1. change currencies,
2. buy a power adapter to allow me to use my US appliances in France,
3. buy a daily ticket for the metro system, and
4. buy a pre-paid phone since Sprint’s CDMA network is completely unavailable in Europe (which is purely GSM).

Changing currencies ended up being the easiest of the four, although I did roughly two laps of the airport lobby before finding the exchange office. Buying a power adapter ended up being simple as well, although I had a false start, almost walking out the store before realizing that what I had in my hand was 1) Europe to US, not US to Europe, and 2) unpaid for! Lesson one: focus. I always thought my Dad was a bit funny, he is like a machine when in an airport, especially in a foreign country. Now I understand why. You make your list, focus, and tackle the items one at a time.

Metro tickets were a little more difficult. There are many automated booths in the airport lobby, but they only sell one-way tickets (or least, that is all I could get them to sell me). I did not want a one-way ticket, or even a book of one way tickets. I wanted a day-pass. I did not want to waste all my tickets if I got lost, and I had been told a day-pass provides unlimited rides. Lesson two: the information people (indeed, most people in general) speak english. Swallow your pride, admit you have no clue how to get what you need, and politely ask the people paid to answer your questions. After a short wait in a line, I had not just a one-day pass, but a pass that covered my entire trip! The ticket clerk was able to direct me to a much better deal than I was about to buy.

Alas, my fourth goal remains unfulfilled. The information desk informed me that they did sell pre-paid SIM cards, but not pre-paid phones. Thank you again, Sprint, for using a dieing technology that no-one else in the world uses. At any rate, I was ready to journey out into Paris!

The Journey to the Office

The first challenge was the transportation system. Instead of taking a cab to our Meudon office (Meudon is basically a suburb of Paris), I elected to take the metro. I figured it would save the company a tidy sum and be a fun experience. I was not dissapointed. I have ridden on the New York subway system, and travelled the tri-state area by train, but the public transportation system in Paris dwarfs either of those, both in complexity and sheer size.

I had two exchanges from the airport to the office, changing from one subway train to another and finally to an above-ground tram. If you are transferring from one subway train to another you never have to leave the subway system. Just follow the signs that lead you through the underground labarynth to your connection. It really is very simple if you just follow the signs. I can not read French. It took me a little while to figure out what the signs were. So I did the stairmaster 2000: walking out of the subway, looking up, seeing the number for my connection pointing down the same stairs I just walked up, turning sheepishly around, and going back down! Ah what fun!

Ok, mastered the subway signs. Once you get them, you get them. Simple! Now to transfer to the tram. Until this point, I did not know there was a tram in addition to the subway system. I thought T2 indicated a bus route (T for trolley?). Ten minutes later, no buses labeled 2, but look! A sign very similar to the subway signs, saying T2. Hrmm…

Ok, I am on the tram platform, boarding the tram, inserting my ticket, declined! Wait, this is supposed to get me anywhere! Well, I do not want to be the rude, law-breaking American, so let’s hop off the tram.  I went to the ticket counter to buy tram tickets, and fortunately the ticket lady realized I had the day-pass.

Apparently, with the day-pass, you do not swipe, or insert your pass. You just get on the tram. If anyone asks, you show them your day pass. Great! Except now I feel like all the regular riders are  looking at me, the ignorant American that thinks the tram is free! “No! I have a day-pass, really!” They, of course, have more permanant passes that you just badge against the door when you board.

Finally, I exited the tram, but I took the wrong exit off the platform and found myself across the street from where I wanted to be. Well, to be honest, I did not find myself until about ten minutes later, when the office failed to materialize! After a bit of backtracking, and more careful sign reading, I made it to the office! This brings me to 10AM, the start of my day.

Notes and Learning and Stuff

This part of my day was pretty straightforward. I received a presentation, the training I was there for. I now have ten pages of hand-written notes! Ten pages! From one day, not even the full day, just six hours! Good stuff.

Side note: for school, I usually type all my notes, but that is mostly to make sure I get everything the professor could possibly have on an exam, I usually already know the material. When I am trying to learn something really new, I always write it out by hand and transcribe it later. I find that my mind is more engaged in the subject when I am writing. I think when typing, I tend to focus on keeping up with the speaker, following the words, not the thoughts. I can not write fast enough to capture all of it; it forces me to distill the thoughts to what I can keep up with.

The day flew by pretty quickly. We stopped for lunch pretty early, as I had not been able to grab breakfast before coming in. The Meudon office has a dedicated cafeteria, like we did when we were still at the Schlumberger property. It was expensive! But I was hungry, and expensing costs.

After lunch, I had the best cup of coffee I have ever had. Seriously, it was a caffe machiato and it beat anything I have had at any Starbucks, hands down. Here is the kicker: it was made by a machine. Yeah, one of those automatic dispenser machines that drop a cup down, brews up some coffee, and adds cream and sugar. It knows how to make some twenty types of coffee: expresso, mocha lattes, cocoa lattes (yum!), americanos, etc. Oh, it was free. FREE. The best cup of coffee I have ever had was FREE from a machine in our developers’ offices. The French may not be able to win wars, but they make a mean cup of coffee!

The Hotel

At about 7:30, we headed out of the office and on our seperate ways. I headed to the hotel, just two stops down on the tram. As I was standing in line in the hotel lobby, I could not help but notice overhear the concierge very patiently trying to help someone over the phone. While she maintained a very patient, helpful tone of voice, you could tell the person on the other end was being obnoxious. Inwardly I hoped that when she was done it would be my time to go forward. It would be the perfect contrast to her rude customer: I will be overly polite and kind, and my request is easy, no sweat.

Well, it seemed like a good plan. Do not worry, I was nice, very nice. But my situation was not easy. We reserved my room by credit card before I ever left. The plan was: go up, check in, charge the room to the card details already present. The hotel needed an imprint of the card as a guarantee before they would release any room keys to me. The card was back with my manager in America, and no, I did not have another card I could use, just as a guarantee, none of my personal cards allow international transactions, so I did not even bring them. Ten minutes later, we had left a message for my manager, and I had paid in cash for the room (to be refunded when the credit card transaction clears). We thought this might happen, so I had enough money. It was not the easy request I thought, but the poor lady did seem more relaxed, so mission still accomplished!

Dinner

More Fun on the Subway

• Expected time: 1 hour
• Actual time: 3 hours

• No dynamic memory allocation (malloc()/free(), new/delete), aka no heap allocations.
• No STL containers

Up until now, these restrictions haven’t really mattered. But this problem was one that would have been much simpler to write using STL containers and dynamic memory. Instead, we are using cstrings, and arrays allocated on the stack for all our data structures. In the end, this probably a good bit faster, but we definitly had some brain-twisting moments. For example, we maintained a list of all the votes currently given to any particular candidate. The datastructure for this is an array  indexed by candidate number of arrays containing indices into the main array of votes representing the votes for each candidate. The length of each of these arrays is equal to the running total of votes for the given candidate. So votes[votesFor[0][0]] represents the first vote that is currently for candidate 0. Of course, the votes array is a two-dimensional array as well, an array of preference arrays and we also need an array to hold the index of the current preference for any given vote. If candidate 0 lost, we need to reassign the vote to the next elegible person in the vote’s preference list. votes[votesFor[0][0]][curPref[0]++] shows us the nest preference for that vote. Add in variables for all the hardcoded values and this can get confusing fast.

• Estimated time to complete: 10 hours.
• Actual time to complete: ~7-8 hours
• Execution time: 0.172
• Rank: 26 28

Installing

Mercurial is easy to install on most platforms:

Binary Packages are available from the Mercurial website for Windows, an array of Linuxes, and Mac.

TortoiseHg: Mercurial integrated with the Windows Explorer (does not provide command-line access). If you prefer working from the Windows GUI, you may prefer this. If you have ever used TortoiseSVN, TortoiseHg is very similar. As of the time of writing the latest version is http://bitbucket.org/tortoisehg/stable/downloads/TortoiseHg-0.8.2-hg-1.3.1-1444a42f6052.exe

Ubuntu

Installing Mercurial is easy via apt-get:

sudo apt-get install mercurial

UTCS Machines

The UTCS machines already have Mercurial 1.3.1 installed.

Basic Usage

Let’s walk through project 1: Collatz,  using Mercurial. All of the examples I will give are on the command line. All actions work the same from TortoiseHg. Quick note on formatting:

Commands will be monospace, flushed to the left.
  Output from a command will also be monospace, but indented

• First, lets create a new Mercurial repository for our project:

  mkdir project1
  cd project1
  hg init

  If we list the directory contents, we will see a newly created .hg folder.

  ls -al
    drwxr-xr-x 3 jdbernard jdbernard 4096 2009-09-22 10:31 .
    drwxr-xr-x 4 jdbernard jdbernard 4096 2009-09-22 10:31 ..
    drwxr-xr-x 3 jdbernard jdbernard 4096 2009-09-22 10:31 .hg

  If you looked at an SVN working copy, you would have noticed a similar .svn folder. There are a few important differences between what the .svn and .hg folders contain and mean:
  • When you did a checkout from SVN, you were not getting the full repository. When you create a Mercurial repository, everything is present. The working copy of a Mercurial repository is the entire repository, including its full history.
  • The .svn folder is the SVN administration area. You will see one .svn folder in every directory of your project. The .svn folder is used to track changes and properties of the files in the current folder relative to the central repository maintained somewhere else (Google Projects for example).
  • The .hg folder is not just an admin area, it IS the repository. You will also notice that there is only one .hg folder in the root directory.
  I feel it is worth pausing here to underscore an important distinction between using SVN and Mercurial. When you checkout some portion of a project from SVN, you are copying only the directory and revision you check out. This means you must have access to the SVN central repository to do most version control activities. With Mercurial, when you ‘checkout’ a project, you actually make a full copy of the repository. So one valid way to ‘checkout’ a project into a new directory is just to copy the project directory. The hg clone command is a fancy version of this simple copy, but we will get to that later.
• Now we’ll grab the initial sources from the links on the Collatz blog post. No hg new commands here, just wget to download stuff.

  COLLATZ=http://www.cs.utexas.edu/users/downing/projects/c++/collatz
  wget $COLLATZ/Collatz.txt
  wget $COLLATZ/main.c++
  wget $COLLATZ/TestCollatz.h
  wget $COLLATZ/Collatz.in
  wget $COLLATZ/Collatz.out
  wget $COLLATZ/TestCollatz.out

• Before we go any further, let’s look at two important commands: hg status and hg log.
  • hg status lists all the changes in the working directory which have not been committed.
  • hg log is similar to looking at the changelog from SVN. It lists the history of commits, the committer, and the commit message for that commit.

  hg status
    ? Collatz.in
    ? Collatz.out
    ? Collatz.txt
    ? TestCollatz.h
    ? TestCollatz.out
    ? main.c++
  
  hg log
    (nothing here yet)

  This illustrates another important point regarding Mercurial. Think of the .hg directory as the repository and the current directory as the working copy. hg status tells us that there are files in the working copy that are not under version control. hg log tells us that the repository has no history at this point.
• So let’s add our initial files to the repository. We can either add them one at a time:

  hg add Collatz.txt main.c++ TestCollatz.h Collatz.in Collatz.out TestCollatz.out

  or we can add the current directory, which recursively adds its contents:

  hg add .
    adding Collatz.in
    adding Collatz.out
    adding Collatz.txt
    adding TestCollatz.h
    adding TestCollatz.out
    adding main.c++

  You can see that if we do not explicitly tell Mercurial which files to add, it will tell us which files it is adding. Let’s see what our working directory looks like now:

  hg status
    A Collatz.in
    A Collatz.out
    A Collatz.txt
    A TestCollatz.h
    A TestCollatz.out
    A main.c++
  
  hg log
    (still nothing here)

  We see that the ‘?’ changed to ‘A’ for the files we added. In general, the first character from the hg status command indicates the status of the particular file.
  • ‘A’ means it is present in the working copy but not in the last revision and it will be added once we commit.
  • ‘R’ means it is present in the last revision but not in the working copy and it will be removed once we commit.
  • ‘M’ means that the file is modified in the working copy relative to the last revision and the modifications will be applied once we commit.
  • ‘?’ means that the file is unknown to Mercurial and will be ignored if we do a plain commit.
  There is one other way to add files which is even easier than hg add . and that is if we wait until we commit and we tell Mercurial to automatically add all files that are different.We will look at this after looking at basic commit usage.
• So lets start committing:

  hg commit -m "Initial commit"
  hg status
    (nothing here)
  
  hg log
    changeset:   0:2740894f4023
    tag:         tip
    user:        Jonathan Bernard
    date:        Tue Sep 22 11:05:57 2009 -0500
    summary:     Initial commit

  Now we see an entry in the log.
  • changeset: each revision has two names in a Mercurial repository. It has a revision number, left of the colon (’0′ in this case) and a digest value right of the colon. The digest is a hash computed over the changes committed for this revision. This is getting a little ahead of ourselves, but it is fairly common for revision numbers to change. If two people both have their own copy of this repository and they both do a commit before merging, then they will both have different revsions named ‘1′. So we cannot always use the revision number as a unique identifier for a revision. The hash, however, does uniquely identify the revision.
  • tag: tags in Mercurial operate differently than tags in SVN. I will not go into detail here, but Google provides answers easily.
  • user: is the username of the user performing the commit. This will default to your unix username.
  • date: time stamp of when the commit was performed.
  • summary: is the beginning of the commit message you provided. The example I gave provides a short commit message on the command line. If you do not provide a message Mercurial will open an editor (looks at either the EDITOR or HGEDITOR evironment variables) for you to write a commit message. The summary shows the commit message up to the first period. So a good practice when writing longer commit messages is to provide a summary of the commit in one sentence before writing out the details.
• Let’s make some more changes and commit them. Edit main.c++ and add the following just before the definition of eval:

  /**
   * cycleLength
   * Computes the cycle length for the given number
   */
  int cycleLength(unsigned long n) {
  
    assert(n > 0 && n <= 1000000);   int temp = n;   int cl = 1;   while(n != 1){     if(n%2 == 0){ /* even */       cl++;       n = n >> 1;
      }
      else{           /* odd */
        n = n + (n >> 1) + 1;
        cl = cl + 2;
      }
    }
  
    assert(cl > 0);
  
    return cl;
  }

  Before we commit, let’s check the status:

  hg status
    M main.c++

  As expected, main is modified. Let’s commit:

  hg commit -m "Added cycleLength function."
  hg log
    changeset:   1:95f4400ad38a
    tag:         tip
    user:        Jonathan Bernard
    date:        Wed Sep 23 08:06:01 2009 -0500
    summary:     Added cycleLength function.
  
    changeset:   0:2740894f4023
    user:        Jonathan Bernard
    date:        Tue Sep 22 11:05:57 2009 -0500
    summary:     Initial commit

  Notice that the revision number for the latest commit is revision 1 and the ‘tip’ tag automatically moved to the latest revision. One other command I want to show you before moving on is the hg diff command.

  hg diff
    (nothing here)
  
  hg diff -r 0 -r 1
    diff -r 2740894f4023 -r 95f4400ad38a main.c++
    --- a/main.c++  Tue Sep 22 11:05:57 2009 -0500
    +++ b/main.c++  Wed Sep 23 08:06:01 2009 -0500
    @@ -68,6 +68,32 @@
         in >> j;
         return true;}
  
    +/**
    + * cycleLength
    + * Computes the cycle length for the given number
    + */
    +int cycleLength(unsigned long n) {
    +
    +  assert(n > 0 && n <= 1000000);   +  int temp = n;   +  int cl = 1;   +   +  while(n != 1){   +    if(n%2 == 0){   /* even */   +      cl++;   +      n = n >> 1;
    +    }
    +    else{           /* odd */
    +      n = n + (n >> 1) + 1;
    +      cl = cl + 2;
    +    }
    +  }
    +
    +  assert(cl > 0);
    +
    +  return cl;
    +}
    +
     // ----
     // eval
     // ----

  Two things to note: the first call to hg diff printed nothing. By default, hg diff shows the differences between the working directory and the latest revision. Since we just committed, there are no differences. The second time I called it passing two revision numbers. Obviously, those two revisions are being compared. Instead of a revision number, I could have given it a tag (for rev. 1) or the unique name for the revision. You can change the diff program used. That is outside the scope of this post, look into the Extdiff extension and the general Mercurial merge program options.
• Say we wanted to go back to the initial commit, before our latest modification. We want to ‘checkout’ a previous revision.

  hg update -r 0
    1 files updated, 0 files merged, 0 files removed, 0 files unresolved
  hg status
    (nothing printed)
  hg log
    changeset:   1:95f4400ad38a
    tag:         tip
    user:        Jonathan Bernard
    date:        Wed Sep 23 08:06:01 2009 -0500
    summary:     Added cycleLength function.
  
    changeset:   0:2740894f4023
    user:        Jonathan Bernard
    date:        Tue Sep 22 11:05:57 2009 -0500
    summary:     Initial commit
  
  hg identify
    2740894f4023

  hg update updates our working directory to reflect the revision we gave it. If we do not give it a revision, it defaults to the latest revision. hg status shows no modifications in the working directory relative to the repository, but hg log shows us that the repository is unchanged. If we look at mani.c++, we can clearly see that the cycleLength function we added is missing. So we see that hg status (and diff, etc) compare to the revision that is currently checked out. hg identify tells us which revision is currently in the working directory. Let’s go back to the latest revision.

  hg up
    1 files updated, 0 files merged, 0 files removed, 0 files unresolved

  For fun, let’s change main.c++ and then try to go back to revision 0.

  echo "This is my nonsensical change." > main.c++
  hg status
    M main.c++
  hg up -r 0
    0 files updated, 0 files merged, 0 files removed, 0 files unresolved
  hg status
    M main.c++
  hg identify
    2740894f4023+

  The important thing to notice is that it did not revert our modified main.c++ file. Mercurial does not want to wipe out changes that we have made if they have not been committed. Also, hg identify adds a ‘+’ to indicate that there are modifications in the working directory. Of course, we can tell Mercurial that we don’t care about our current modifications, we just want revision 0.

  hg up -r 0 -C
    1 files updated, 0 files merged, 0 files removed, 0 files unresolved
  hg status
    (no output)

More Information

Mercurial has an excellent built-in help system. Running hg help gives you a list of available commands and hg help <command> will give you detailed information about a particular command.

Additionally, there are many excellent tutorials and much fine documentation available online. My recommendations for further reading are:

• Quick Start
• Tutorial on the Mercurial website: a more detailed version of what I’ve done here.
• Understanding Mercurial: a more detailed explanation of what is going on when you create revisions, etc.
• Mercurial: The Definitive Guide: an excellent book on Mercurial. Great detail.
• HOWTOs: common uses of Mercurial
• Branches: an explanation of branching in Mercurial

Final Note: most of this discussion of Mercurial also applies to Git. The workflow and repository concepts are very similar. The commands themselves overlap more often than not. If you know Git, there is almost no learning curve moving to Mercurial and if you know Mercurial, there is almost no learning curve moving to Git.

The time on the UVA machines for our submission varried by about .004 in either direction when we submitted. The best time I recieved from UVA was 0.096, ranked 380-ish last time I checked, but I may have been bumped down a bit (at the time of this post I can not reach the UVA site, hrmm).

I’ve done 3n+1 before, so the problem itself seemed trivial. More than just the naive solution, I have implemented the caching suggestions Downing mentioned in the past as well. My estimate for time to complete was an hour max for the naive version and two hours max for the lazy cache + metacache version. The actual times were pretty close to my estimates, though backwards. The actual time it took me to write the naive version was about an hour and a half. I had the program done in 30 minutes or so, but I could not get it accepted to UVA. An hour later I decided to cheat a little and look at how I had solved it before (my own work, not really cheating, grader). Ah! I forgot that the input can be in either order, you are not guaranteed to read the smaller number first. Ok, fixed and submitted.

My partner and I were not able to meet as often as I would have liked, this is my fault mostly. My schedule made it difficult for us to find time to meet in person. This was mitigated somewhat by the code review feature of Google Project Hosting. Even when we worked independantly on a portion of the code, we could commit our changes and request a code review from the other partner. This way we still had two sets of eyes looking over any piece of code, even if we could not physically work together.

Lincoln (my partner) did most of the work for implementing the lazy caching, so the time to complete the optimized version of the project was only a half hour or so. The metacache functionality worked the first time I tried it (yay for unit testing as you go and writing small modular pieces). I varied the cache parameters to try and find the best fit within the 40KB source limitation UVA imposes. I think I could probably shave a little more time off of our submission, but I’m content. Our final running time at UVA was 0.016 and our rank was 318th. Not too bad.

There is one more thing that I think is worth mentioning. Initially, I was using a couple Groovy scripts to automate some of the work I would normally do by hand: things like debuging the algorithm and generating cppunit code based on the collatz output (from the naive version). When I asked, I was told I must use C++ for everything. While I understand this requirement, I think it somewhat out of place. Different tools have different purposes and strengths. C++ is not well suited to the rapid, prototyping style of development that Groovy enables. Maybe I’ll blog about this later. So I went about translating my Groovy scripts to C++. This took roughly 10 hours. A large portion of this time was spent implementing a relatively simple command line option parser in C++ (you get the Apache Commons CLI built-in with Groovy). Getting this small library to compile and run with no error and no Valgrind complaints was a lesson worth the time. The best way to learn to program is to program. Invest the time, you will be rewarded.

Sometime after project 2 I will post a link to the google code repository where this library lives. By the way, if you are looking for a command line library, there are a number of good ones already out there: tclap, argtable, and AnyOption are some places to start.

Love is a commitment first and foremost. A commitment to honor, cherish, and protect the object of your love. A commitment to the emotional, physical, and spiritual well-being of the one you love. A commitment to think of your loved one first and to provide for their needs first. True love says no-one and no-thing can dissuade my commitment to you. True love is very emotional, but true love is not an emotion. True love is a commitment.

One second about divorce. Divorce does not happen when there is true love. True love is not an emotion and does not change day to day. True love can be lost, if it is not tended to. Divorce is only the legal and public display of a commitment that has faded of its own accord. Any relationship can be saved, if both parties are willing to work on it. True love says I am willing to change to accommodate you. Both the husband and the wife will be supremely happy when they both adopt this attitude. True love does not say, “This is how it must be for me to be happy.” True love asks, “How can I make you happy.” When both spouses think like this, they will find that they are both happy.

True love honors the other. This means that true love looks for ways to truthfully praise and to esteem the loved one. Empty praise is just that. Praise for the sake of praise alone is not genuine. But real praise and real appreciation, coming from the heart, lift and fill a person with life. Small things work just as well as large. Actions work better than words, though both are required. Love covers a multitude of sins, and this is not restricted to the love of our Savior. This expression of love through praise and affection creates a buffer against small annoyances and grievances. When this buffer of honor and esteem are lost, every little thing has the potential to escalate into a deadly argument. The key is not extravagance but consistency and honesty. Examples: “Thank you for working a hard day today. It is nice to not worry about bills,” and then, do not worry about the bills. “Thank you for taking care of the laundry! I appreciate having fresh, clean clothes to start the day,” and then, do not casually toss dirty clothes on the floor, bed, or chair (I am guilty here!).

True love cherishes the other. This means that they are valuable to you. This part is easy to miss in the day to day of life. Do not take your loved one for granted! Make their time valuable to you. I often find myself wanting in this regard. Are you always busy when you have time together? Is there always something you would rather be doing when you are spending time with your loved one? This is deadly for any relationship. It causes a distance and a gap. Your kids and your spouse will know how valuable they are to you by how you spend your time. That first crush and first dating experience sticks with you. You can almost fall in love with dating as much as the person, because there is someone who values you and thinks you are special. This is what leads to so much of the romance in a dating or courting relationship. That feeling of love (love is a commitment) comes from being cherished and cherishing the one you love. If you want to restore that feeling in your relationship, start showing your partner how much you value them. Gifts are only valuable if they are a real expression of how much you value your partner. You can give your kids the gift of confidence in all of their life by showing them that they are important to you. You teach them that they are valuable and that what they do is valuable. They will need this later in life to build healthy relationships of their own. I will talk more about this in another post.

True love causes you to protect the one you love. True love values the loved one, and true love seeks to protect that loved one. Beyond the obvious physical protection, this means you are protective of their self-worth and the things that they value. For example: you do not get glory, esteem, or pleasure at the expense of the one you love. Parents, never tell people about how you saved your kids from doing something stupid, or had to fix their mistake. You are raising your own ego at the expense of theirs. This tears them down, it does not protect them. Kids, and people in general, are going to make mistakes, sometimes when they have been told better. It is part of how people learn and grow (not just kids). Your reaction to their mistakes can have a stronger and longer-lasting impact on them than their mistake itself. For any relationship of love, the ones you love must know that they are safe with you. They are safe to be who they are and you will not attack them, or cut them down for it. They are safe knowing that if they make mistakes you will be there to help them overcome those mistakes, not to kick them while they are down. This is one of the most important attitudes of love a church family needs to have towards one another. The cherishing of love cannot happen if there is no safety in the relationship. It has often been said that those closest to you are those that hurt you the most. Let us look at this from the perspective of love, not I-based. Translated it is: those who are the closest to me are the ones I have the greatest power to hurt. So I must protect my loved ones from myself as much as from anything else. This is where self-control and purposeful actions come into play, more on that later.

I have been blessed in my life to be on the receiving end of such love. Now as a husband and a father, I endeavor to give love like this to my wife and kids. There is far more to be said about love and I will post more later. Also, as I discover new truths about love, I will revise my understanding here.