Though I've enjoyed having my blog on this site for some time I've decided to change it up a little and move to a different host.  My blog will continue at the following location 

https://blog.paranoidcoding.com/

Note that this post is specifically about how I interview college candidates or candidates with a small number of years in the industry.  I have a much different process for senior level developers (which is more of what I do these days).

Pre Interview Setup

The candidate deserves my undivided attention during the interview.  Before I go out to greet the candidate I turn my phone off and put it in my desk, close my email, turn off the speakers to my computer and lock the screen.  The only visible distraction I have is a clock to make sure I’m keeping the interview moving along. 

The Introduction

My very first goal in an interview is to make sure the candidate is comfortable in the environment. Interviewing is a nerve racking experience for some people (especially college candidates who are quite possibly doing this for the first time ever).  I’m rarely the first person on an interview loop and hence I often have to deal with candidates that are tired or perhaps rattled a bit by an interview earlier in the day.  I find people perform best when they are in a relaxed environment and I do my best to get them there.

One technique I’ve found that helps relax people is to get them talking about something they are passionate about.  I get every candidates resume a day or two before the interview and I look over it in detail.  I’m looking for anything that they have put significant time or effort into: a senior project, GitHub contributions, stack overflow, etc … 

Once I find that project I spend 30 minutes or so researching it myself.  My goal is to get enough of an understanding of the project that I can have a conversation about it.  I also write down some really easy questions about the project.  Presenting the candidate with questions on subjects they are passionate about is a good way to get the candidate relaxed and give them an early confidence boost.  It’s much better then starting them off with questions I’m passionate about

I usually start off with the standard small talk.  Who I am, how long I’ve been here and what groups I’ve worked in at Microsoft.  I ask them the same about themselves and then transition into the research I’ve done on them

I was looking over your resume and noticed your senior project on improving TCP startup.  Tell me about that. 

Some people are happy to go on at length here and some are a bit more reserved.  For the reserved I prompt them with the questions I’ve already written down.

Why is TCP intentionally slow at startup?

Your project focused on improving algorithm X, what was wrong with it?

Remember the goal here is to relax the candidate and increase their confidence.  Take their project, craft easy questions for it based on the work their project said they did.  Let them shine here. 

I generally reserve 10-15 minutes for this section of the interview

The Technical Interview

I start the technical portion off with a very easy and vaguely worded question.  My favorite question is the following

Write a function that takes a collection of letters and determines if there are any duplicate letters

The candidate is free to constrain this problem however they like

Can I use a hash table?  Sure

Can I assume the letters are all ASCII? Sure

Can I assume they come in sorted order? Sure

Can I sort them? Sure

Can I use something like bubble sort to check every combination? Sure

I do this for a couple of reason.  In part I want to keep the candidate comfortable and give them an easy win on the white board.  I don’t care how they solve it, just that they can solve it.  It’s a modified fizzbuzz problem that tells me they can at least write code in the language of their choosing.  The other reason I do this is because I’m curious to see what questions they will ask (if they ask any).  What they ask often reveals a good deal on how they approach coding.

After they get the solution correct and we walk through it I start taking things away. 

That hash table makes it easy doesn’t it?  How would you solve it without a hash table?

ASCII really makes the problem easy.  How would you solve it with Unicode characters?

Could you solve this without allocating any memory?

I make subtle changes to the question that make the solution incrementally harder and gauge how they react to the changes.  I do want to stress incrementally here.  I don’t go from easy to hard with a single twist.  Instead I add constraints to gradually and incrementally up the difficulty. 

It’s not critical that they solve every twist I give them.  Really what I’m after here is how they think about coding and whether or not they can adapt their solution to changing requirements (aka my life as a programmer).  I’m also curious how they react on a personal level to the changes.  Do they get angry, excited, etc …

Throughout this section of the interview there is one thing I’m constantly vigilant about

Do not ever let the interview session go stale for more than 5-10 seconds

There is 0 value in having an interview where me and the candidate are just staring at each other silently for several minutes.  If they get stuck on a problem it is my job as the interviewer is to help get them unstuck.  Ask them what they’re stuck on, what they’ve considered, get them to draw out sample input, anything that gets them talking or writing on the white board.

My time reservation for this section is 35-40 minutes but I’m a bit more flexible.  If the candidate is a clear hire I usually stop earlier and spend more time on selling, answering questions.  If a candidate is struggling I give them as much time as possible to get to a good solution. 

The Wrap Up Conversation

In general I let the interview wrap up be very candidate driven.  I open the floor for questions they have.  If they don’t have any I try and answer the most common questions

• What is the environment in my group like
• What are the ups and downs of my group
• What is life in Seattle like
• Why did I pick Microsoft over company X

It is really important in the wrap up to make sure the candidate leaves feeling good about the interview.  Even if the candidate completely and utterly screwed up the interview I try to make sure they leave feeling good about the session.  They could have just had a bad day, you may have just asked them the one question they couldn’t answer.  It’s very possible that you are the only “No Hire” they will get all day long.  Or maybe they’re not good enough now but a year from now they’ve gotten enough better that they nail the interview and you end up working with them. 

To sum it up in one statement … 

Never let a candidate leave feeling bad about themselves. 

Unfortunately this feature does not work on all project types including VSIX projects.  This meant that Visual Studio Extension authors who wanted to developer extensions for all versions of Visual Studio were essentially locked into editing that code with 2010.   This is doubly unfortunate given that extension authors are the type of developers most likely to early adopt new versions of Visual Studio. 

The good news though is that it is possible to have a VSIX project be round tripped, it just requires a bit of special sauce to get working.  Once done though a VSIX project can be fully edited, F5’d, etc … in any version of Visual Studio. 

Originally this blog post was going to be a step by step process for getting a 2010 VSIX project into full round tripping mode.  However as I started to write the post it was looking rather dull.  Virtually every line was a variant of

• Open File <…>
• Paste <this odd snippet> on line <…>

After pasting some rather ugly MsBuild XML into my post I realized that there was a much better way to convey this information: actually demonstrating the transition from a 2010 extension to a fully round trippable one on a real project.  Essentially I decided the best way to do this was to speak in code. 

Hence I created a GitHub project that starts with a simple 2010 extension and step by step (or commit by commit) turns it into a fully round trippable one.  Every commit has detailed comments about why the edits were taken, what features they provide and what limitations remain. The full transition is available here

• GitHub Project: https://github.com/jaredpar/RoundTripVSIX
• Commit Log: https://github.com/jaredpar/RoundTripVSIX/commits/master

I hope that this speaks better to other extension developers out there and helps them get to a happy round trippable world. 

https://blogs.msdn.com/b/dotnet/archive/2013/06/24/please-welcome-immutablearray.aspx

Unfortunately with every announcement around these collections I keep seeing the following going past in my twitter feed.

That looks neat.  Next time I’m writing parallel code I’m going to try that out.

No, no no!!!  Immutable types are not just for parallel code.  They are very useful in even single threaded applications.  Developers are missing out by thinking of them as a parallel only construct.  Any time you want to enforce that the contents of a collection never change you should consider an immutable type.

The Provider

Consider the case of an object which provides a collection to callers where the contents never change.  Something like Assembly.Modules.  A type like Assembly must be robust in the face of misuse by any caller and always present the same set of Module values.   Given this constraint what type should it use though for the property? 

It can’t do something as simple as using a List<Module> with a similarly typed backing field.  Returning such a value would allow a devious caller to clear the list and spoil the results for everyone else.   It cannot even store a List<T> internally and return an IEnumerable<T> as anyone could just come along and down cast to List<T> and clear the collection. 

Assembly assembly = ...;
// Evil laugh
((List<Module>)assembly.Modules).Clear(); 

Instead it chooses to be robust by returning a freshly allocated array on every single call to Modules [1].  This works but is a very wasteful process and results in many unnecessary allocations. 

If this API were being designed today this would be a perfect candidate for using ImmutableArray<T>.  This value can be safely stored and returned with no fear of the caller deviously mutating the result.  There is simply no way of doing so. 

The Consumer

Now consider the case of the consumer who wants to store a collection of Modules instances and do multiple lazy independent calculations on them.  In order for the different calculations to be correct they need to ensure the collection of Module instances don’t change from operation to operation.  Hence they have to make a decision when storing the collection in the constructor

class Container {
   IEnumerable<Module> m_modules;

   public Container(IEnumerable<Module> modules) { 
     // Do I trust my caller??? 
     m_modules = modules;
   }
}

The constructor can choose to do one of the following

1. Create a private copy of the input collection that it doesn’t mutate
2. Create no copy and hope that the caller never mutates the input collection

The first option is wasteful and the second is just a bug waiting to happen a year from now when someone decides to reuse a List<Module> for another purpose.  With immutable types the container has a much better third option: demand a collection that never changes

class Container {
   ImmutableArray<Module> m_modules;

   public Container(ImmutableArray<Module> modules) { 
     // Trust no one 
     m_modules = modules;
   }
}

The callee has now forcefully stated to the caller exactly what type of data it expects.  It no longer has to make a wasteful copy or hope for good behavior.  True this may force the caller to create an immutable copy of the value it holds.  It’s also just as likely that the caller will be in a position to provide the collection without any copies.  If it takes the collection as input it can simply pass along the requirement in its parameter list.  Or if it is the original creator of the collection it can do so as an ImmutableArray<Module> from the start and avoid the extra copy altogether.  Over time, code bases which are assertive about using immutable collections will see a decrease in allocations because they will feel more comfortable with sharing data between independent components. 

This is just a small sample of cases where immutable collections are useful in day to day code.  The more you use them the more uses you will find for them.  At some point you may even find yourself asking the following question when writing up a type

Do I actually need to mutate this collection after I finish building it?

Generally speaking the answer to this is no.  And this is why you should be using immutable types. 

[1] If you dig deep into the implementation you’ll find it’s actually a fresh array of RuntimeModule[].  So even though they allocate a new array on every call you can’t safely write Module instances into it unless they happen to be instances of RuntimeModule.  So wasteful!

        Task<int> task = ...;
        int local = await task;
        Use(local);

What most people don’t consider is the implications of this non-blocking support.  At the point the ”await task” expression executes the program can do one of two things.  If task is resolved the await expression will complete and the method will continue executing immediately.  If it’s not then the method will pause and some other part of the program will wake up and start running.  This other code interleaves with with the execution of this method.  This means subtle timing changes in when Task values are resolved can drastically alter the order in which a program executes.

These method interleavings can be the source of many subtle bugs in the program.  They are typically timing related and hence often don’t predictably reproduce and possibly don’t show up at all until the program is executing on a customers machine.  One of the most common bugs I see is when developers mistakenly combine compound assignment with the await keyword

        x += await y;

The C# compiler will rewrite this code into roughly the following [1]

        x = x + await y;

And it executes in the following steps

1. load x onto the stack
2. await y
3. Push result of “await y” onto the stack
4. Add the stack values
5. Store into x

In the case where “y” isn’t resolved the execution of this code will stop at step #2.  At which point some other code will begin executing in its place.  If “x” is a local there isn’t much danger here but what if “x” represents a field that is accessible to another part of the program?  And what if that field is modified while this expression is paused at #2?  When this statement resumes it will never re-read the value of “x” and hence any writes to it which occurred during the pause will be erased once the expression completes.  Or in other words, it will quite simply ignore the other write. 

I most frequently see this problem with accumulator scenarios.  A collection of tasks are spun up and the results are tallied up as they complete

    class Accumulator
    {
        private int m_sum;

        public int Sum
        {
            get { return m_sum; }
        }

        public async Task Add(Task<int> value)
        {
            m_sum += await value;
        }
    }

This code is fundamentally incorrect because it invites this very problem.  Consider the following scenario

1. Call to Add is made with an unresolved Task.  Add pauses on the task having already read m_sum onto the stack
2. Call to Add is made with a resolved Task with a value of 4.  Add completes and m_sum is now 4
3. Task from step 1 resolves with a value of 2.  The value on the stack for m_sum is still 0 so m_sum is written out as 2 instead of 6

The way to avoid this problem is to simply not mix await and the compound operator.  Instead store the await value into a temp and then do the assignment without the risk of interleavings.

        public async Task Add(Task<int> value)
        {
            var temp = await value;
            m_sum += temp;
        }

Here is a sample which will demonstrate the bug in a deterministic fashion. 

        var accumulator = new Accumulator();
        var taskCompletionSource1 = new TaskCompletionSource<int>();
        var taskCompletionSource2 = new TaskCompletionSource<int>();

        var task1 = accumulator.Add(taskCompletionSource1.Task);
        var task2 = accumulator.Add(taskCompletionSource2.Task);
        taskCompletionSource2.SetResult(3);
        taskCompletionSource1.SetResult(2);

        await task1;
        await task2;

        Console.WriteLine(accumulator.Sum);

This code will print out 2 instead of the expected 5

[1] I use “roughly” here because it the compiler actually does a more complicated rewrite.  It ensures that the side effects of “x” happen exactly once during the execution of this method.  For locals though this is roughly the code that is generated and serves fine for this example 

During a review of some low level bit manipulation logic a developer raised a question about the correctness of a piece of code which allowed any arbitrary byte to be seen as a bool.  No one could recall if true was defined as not 0 or simply 1.  If it was the latter then the code was allowing for a large range of invalid bool values to be created.  A quick look at the CLI spec revealed the immediate answer (partition III section 1.1.2)

A CLI Boolean type occupies 1 byte in memory. A bit pattern of all zeroes denotes a value of false. A bit pattern with any one or more bits set (analogous to a non-zero integer) denotes a value of true.

A quick test backed up this particular assertion.  Any non-zero value is true and 0 is indeed false.  We took the test one step further and discovered, to the surprise of about half of us, that just because two bool values are true, doesn’t mean they’re equal.  

    class Program
    {
        [StructLayout(LayoutKind.Explicit)]
        struct Union
        {
            [FieldOffset(0)]
            internal byte ByteField;

            [FieldOffset(0)]
            internal bool BoolField;
        }

        static void Main(string[] args)
        {
            Union u1 = new Union();
            Union u2 = new Union();
            u1.ByteField = 1;
            u2.ByteField = 2;
            Console.WriteLine(u1.BoolField); // True
            Console.WriteLine(u2.BoolField); // True
            Console.WriteLine(u1.BoolField == u2.BoolField); // False
        }
    }

I was one of those who was surprised

I wanted to blog about my the rules I learned from this exercise because even as a seasoned extension author I hit a couple of very surprising problems along the way.  Hopefully the lessons I learned will help out the next person to attempt this

Utility libraries must be strongly named

This is an unfortunate truth of authoring a utility library in Visual Studio.  If you intend to ever release more than one version of a utility library then you must accept that there will be two extensions referencing different versions of your library in the same instance of Visual Studio.  Unless the assemblies are signed the CLR will only load one version into the AppDomain.  This means one extension will see the version it expects and the others won’t.  This would be disastrous if the newer version of the library had new MEF interfaces, features, etc …

Simply being very diligent with version numbers just isn’t enough here.  When comparing a DLL reference to a DLL loaded in memory the CLR will ignore version numbers on unsigned assemblies [1].  If an app has a reference to MyUtility.dll at Version 99 and MyUtility.dll at Version 1 is loaded the CLR will consider it a match.  There’s nothing I’m aware of, other than strong names, that will change this behavior.

This also means you can’t even rely on the latest version of your utility library being loaded.  Extension load order is not defined in Visual Studio [2].   Hence it’s quite possible that extension referencing the oldest version of your utility library loads first and establishes that version as the one every other extension will use. 

When an assembly is strongly named the CLR will respect version numbers and load multiple versions of the assembly into the AppDomain at the same time.  Every extension will then see the version they are expecting independent of what other extensions are installed on the machine. 

MEF isn’t version safe by default

MEF gives the appearance of being a model that deals in terms of types.  Contracts are typically defined in terms of interfaces, [Export] of the implementation use a typeof experession and the associated [Import] is tagged on a type location.  Everything about it screams Type, yet MEF doesn’t actually deal in terms of types, it primarily deals in terms of strings.  Specifically in the form of a contract name and type name. 

Every export and import have a contract name and type name associated with them.  Only when both the contract name and type name match does MEF consider an Import and Export to match.  Consider:

[Export(typeof(IObjectCache))]
internal sealed class ObjectCache : IObjectCache {

}

The above code did not create an export of the .Net type IObjectCache or even it’s assembly qualified name.  Instead it created an export with

• Contract Name: SomeNamespace.IObjectCache
• Type Name: SomeNamespace.IObjectCache

Note: If you don’t specify a contract name explicitly MEF will just reuse the type name it generates

Notice that no assembly information is captured in this export.  It’s just a type name plus the enclosing namespace.  This contract will match up with any other Export of a type with the same fully qualified name as IObjectCache in any assembly loaded into the AppDomain.  And this is exactly what will happen if you have multiple versions of your library loaded into the Visual Studio process [3]

In order to have version same MEF components the export and import contracts need to be different for different versions of your library.  The easiest way to achieve this is to embed the assembly version into the contract name portion of an Export and Import.  In my projects I achieve this by means of a constant which I reuse in my AssemblyVersion attribute and Exports

public static class Constants {
    public const string AssemblyVersion = "1.0.0.0";
    public const string ContractName = "MyUtility " + AssemblyVersion;
}

[Export(Constants.ContractName, typeof(IObjectCache))]
internal sealed class ObjectCache : IObjectCache {

}

[assembly: AssemblyVersion(Constants.ContractName)]

Unfortunately this messiness isn’t something that can be self contained within your library.  It’s a price you must push down to your consumers as well.  Their [Import] attributes must have the same contract name else MEF won’t consider them a match and will reject the composition.  Hence consumers of your library must use a similar pattern. 

public class MyService {
    [ImportingConstructor]
    public MyService([Import(Constants.ContractName)] IObjectCache objectCache)
    {

    }
}

This applies to all ImportingConstructor, Import and ImportMany usage of your types. 

Both of these lessons set me back quite a bit.  But eventually I was able to produce the EditorUtils package I’d been working on and change VsVim to use it.  Hopefully there aren’t many more surprises waiting for me around the corner …  

[1] Except for Silverlight

[2] Unless there is an explicit entry in the manifest file declaring a dependency. Won’t ever happen for unrelated extensions.

[3] If this surprises you then you’re not alone. I frankly disbelieved the first person who told me this and had to create a sample app to prove it to myself

Link: https://visualstudiogallery.msdn.microsoft.com/en-us/59ca71b3-a4a3-46ca-8fe1-0e90e3f79329

GitHub: https://github.com/jaredpar/VsVim

What does 1.0 mean?

Several people asked me what 1.0 meant for VsVim?  From the first release of the project to the web I’d envisioned 1.0 as the point where I had a highly functional Vim implementation in Visual Studio.   Something a Vim user could add to Visual Studio and become immediately more productive.  Given the feedback I’d been receiving and seeing the trend in filed issues from major features to more minor features and bugs I felt like VsVim met that goal. 

For me personally it’s a significant milestone in what started out as a pet project to do little more than learn F# and the new Visual Studio Editor APIs.  It was only after a few months of toying around in my spare time that I thought it might end up having value to people other than myself.  Even then I was just as interested in publishing a working Visual Studio 2010 editor extension for documentation purposes as I was in the actual functionality (although my primary goal quickly transitioned towards functionality).  I thought it would be great if I ended up with 1000 downloads in the first year.  As of this writing VsVim is at 24,000 downloads and lots of positive community feedback!  It all really exciting for me.

Release Notes

This release is mainly a bug fix release on top of previous releases: particularly in the area of motions and synchronizing settings between Visual Studio and VsVim. 

I do want to take a second and again thank everyone who gave me feedback or filed issues throughout the entire development cycle.  It really helps to have such great feedback to work against. 

The usual caveats and expectations

This extension is being released by me, not by Microsoft.  As such the support level for this extension is equivalent to the amount of free time I have to put into it.

Source for this release is available on the GitHub project site.  It and the associated binaries are released under the MS-PL.

[1] The update was actually released a few weeks ago but in my excitement I forgot to blog about it.

[DebuggerDisplay("Student: {FirstName} {LastName}")]
public sealed class Student {
    public string FirstName { get; set; }
    public string LastName { get; set; }
}

The DebuggerDisplay attribute can customize the name, value and type columns in the debugger window.  Each one can be customized using a string which can contain constant text or expressions to be be evaluated by the expression evaluator.  The latter is designated by putting the expression inside {}’s (this greatly resembles String.Format)

This feature while very powerful and useful can also easily contribute negatively to the debugging experience when used improperly (mostly in the area of performance).  After several years of working in this area and helping customers out with bugs I’ve come up with a few recommendations to help prevent this from happening [1]

Don’t use multiple functions or properties in the display string

Every time I see a DebuggerDisplay attribute like the following I cringe a little inside

[DebuggerDisplay("Student: {FirstName} {LastName} {Age} {Birthday} {Address}")]

Hands down the most expensive operation the expression evaluator does is evaluate a function.  It dwarfs every other performance metric and can have a visible effect on stepping performance [2].   This is true for both functions and properties (as far as the debugger is concerned there is almost no difference between the two). 

Every one of the expression holes above results in a property being evaluated.  Each property must be evaluated individually and done so once for every instance of this type in every debugger display window.  This set of evaluations is repeated on every single step.  This can get very expensive if collections of this type end up getting displayed (imagine stepping with a couple thousand of these in the window!). 

Please don’t read this and remove every property from DebuggerDisplay’s in your code.  One property is very unlikely to cause a problem.  Issues typically arise when many properties are used and collections of that type end getting displayed in the debugger windows. 

Do use property / field names instead of language specific expressions

Evaluation holes in the string are not limited to just properties and function calls.  They can handle pretty much any legal expression you can dream up.  In the past this has lead to developers putting all manner of expressions into DebuggerDisplay attributes.  The most common being the use of ternary expressions

[DebuggerDisplay("Count {IsEmpty ? 0 : Count}")]

While this works fine, please don’t do this!  DebuggerDisplay attributes are evaluated not by the language in which they were defined but by the expression evaluator of the language in which they are being used.  The above works great but only when viewed in a C# application.  It fails miserably when viewed in other languages like VB.Net (and when F# has their own EE it will fail for that as well). 

While there is no truly universal expression one which is supported by most languages is member names.  Having an expression which is a simple property or field goes a long way to removing this problem. 

Don’t evaluate expressions that throw exceptions

Earlier I mentioned that the most expensive action an expression evaluator performs is evaluating a function.  The most expensive variant of evaluating a function are those which throw exceptions.  Please don’t do this. 

Don’t use mutating properties or functions

Usually this goes without saying but I’ve seen enough examples of this to warrant an entry.  Don’t put expressions into DebuggerDisplay values which will mutate the underlying value.  This will lead to only confusion.

Preferred Pattern

My personal preferred pattern for DebuggerDisplay attributes is to have the entire item be an expression: DebuggerDisplay.  I then add a private instance property to my type named DebuggerDisplay and do all of my custom formatting in this property.  Having the property be private is fine because nothing is private in the debugger.

[DebuggerDisplay("{DebuggerDisplay,nq}")]
public sealed class Student {
    public string FirstName { get; set; }
    public string LastName { get; set; }
    private string DebuggerDisplay {
        get { return string.Format("Student: {0} {1}", FirstName, LastName); }
    }
}

The “,nq” suffix here just asks the expression evaluator to remove the quotes when displaying the final value (nq = no quotes). 

I prefer this pattern because it’s only requires a single function to be evaluated, I can still have language specific expressions (which are nicely type checked by the compiler) and it doesn’t contribute to the public API of my type. 

[1] Note the word “I”.  These are not any kind of official recommendations, just several I advocate to people using this feature.

[2] In one performance critical scenario for Visual Studio 2010 over 95% of it was spent evaluating the function! 

Link: https://visualstudiogallery.msdn.microsoft.com/en-us/59ca71b3-a4a3-46ca-8fe1-0e90e3f79329

GitHub: https://github.com/jaredpar/VsVim

This update includes the following

• Lots of undo / redo issues
• Lots of caret positioning issues
• Support for tabs
• And of course many other bug fixes

I do want to take a second and again thank Martin Lemburg for the many detailed issues filed during the 0.9.4 release.  It really helps to have such great feedback to work against.

Note: The latest release is 0.9.5.1.  I released a patched version of 0.9.5 to deal with bad behavior in the ‘%’ motion which was breaking a lot of users.

Future Plans

I’m aiming for 0.9.6 to be a quick release cycle.  The main focus of this release is getting macros and visual block operators working.  I already have macro support working in the beta tree.  I want to spend a few weeks working out the kinks and getting through other bug fixes and then I’ll release 0.9.6. 

Macros represent the last major feature for the 1.0.0 release.  So after 0.9.6 there will maybe be 1 more bug fix release before 1.0.0!

The usual caveats and expectations

This extension is being released by me, not by Microsoft.  As such the support level for this extension is equivalent to the amount of free time I have to put into it.

Source for this release is available on the GitHub project site.  It and the associated binaries are released under theMS-PL.