what can cause Visual Studio to rebuild my entire solution all the time? - Stack Overflow

what can cause Visual Studio to rebuild my entire solution all the time? - Stack Overflow: "You can use the configuration manager to set up a specific config for your sln that will only build the projects you specify. You can find it under Build->Configuration Manager"

This fixed it for me. Somehow one of the projects had become unchecked.

C# Threadsafe Random

    ///     A threadsafe wrapper around .
    public static class Randem {

        private static int seed;

        static Randem() { seed = Environment.TickCount; }

        ///

        ///     Provide to each thread its own .
        ///
        private static readonly ThreadLocal< Random > ThreadSafeRandom = new ThreadLocal< Random >( valueFactory: () => new Random( Interlocked.Increment( ref seed ) ), trackAllValues: false );

        ///

        ///     A thread-local .
        ///
        public static Random Instance { get { return ThreadSafeRandom.Value; } }

        ///

        ///     Returns a random float between and .
        ///
        ///
        ///
        ///
        public static float NextFloat( float min = 0, float max = 1 ) { return ( float ) ( min + ( Instance.NextDouble() * ( max - min ) ) ); }


        ///

        ///     Generate a random number between and .
        ///
        /// The inclusive lower bound of the random number returned.
        /// The exclusive upper bound of the random number returned.
        ///
        public static int Next( int minValue, int maxValue ) { return Instance.Next( minValue: minValue, maxValue: maxValue ); }

C# TakeLast()

        ///

        ///     Remove and return the last item in the list, otherwise return null.
        ///
        ///
        ///
        ///
        public static TType TakeLast( this IList list ) {
            if ( list == null ) {
                throw new ArgumentNullException( "list" );
            }
            var index = list.Count - 1;
            if ( index < 0 ) {
                return default( TType );
            }
            var item = list[ index ];
            list.RemoveAt( index );
            return item;
        }

C# List TakeFirst()

        ///     Remove and return the first item in the list, otherwise return null.
        public static TType TakeFirst( this IList list ) {
            if ( list == null ) {
                throw new ArgumentNullException( "list" );
            }
            if ( list.Count <= 0 ) {
                return default( TType );
            }
            var item = list[ 0 ];
            list.RemoveAt( 0 );
            return item;
        }

C#/.NET Little Wonders: 5 Easy Ways to Combine Sequences

C#/.NET Little Wonders: 5 Easy Ways to Combine Sequences:

If you need to squeeze a little more performance to combine large lists or other enumerable sources, that does not contain any duplicate items, then here's what I've found in my testing:

Fastest, with no duplicates: Concat(list1).Concat(list2).Concat(list3).Concat(list4).Union(list5);

Remember, this style worked the best in my classes. Always test yours..

Designing a Database: 7 Things You don't Want To Do | SQLRockstar | Thomas LaRock

Designing a Database: 7 Things You don't Want To Do | SQLRockstar | Thomas LaRock:

'via Blog this'

Microsoft SQL Server 2012 TempDB Best Practices

Here are my performance guidelines I've gleaned from experience as a DBA and the researching on the internet:

1. Move the primary TempDB.mdf to its own hard drive or the fastest drive in your system.
   • ALTER DATABASE [tempdb] MODIFY FILE (NAME = tempdev, FILENAME = 'T:\TempDB\Tempdb.mdf');
2. Add additional tempdb_N.mdf, one per spindle per physical cpu core.
   • As of 2013 a modern hard drive has one spindle. (A spindle is what the platters rotate around.)
   • Each core should have a fast spindle all to itself.
3. On each tempdb.mdf, set the Autogrowth to 1% and unlimited.
   • Some DBAs recommend setting autogrowth off and setting a maxium initial size to avoid fragmentation and 'pauses' on query executions. I disagree for the simple reason that in MSSQL 2012 tempdb makes good use of its internal bitmaps and will grow with the queries as needed. Never shrink the tempdb unless you need the space.
4. Move the primary TempDB.ldf it its own hard drive or the fastest drive in your system.
• ALTER DATABASE tempdb MODIFY FILE (NAME = templog, FILENAME = 'L:\TempDB\Tempdb.ldf');
5. Restart the server and verify your database changes: select [name], [physical_name] AS [CurrentLocation], [state_desc] from [sys].[master_files] order by [name]
6. Defragment the free space on all drives. I recommend Defraggler or Auslogics Defrag.

ranking functions « Mehroz’s Experiments

ranking functions « Mehroz’s Experiments:

Good stuff !

Thought experiment: stuck in a room with a PC without an OS.

Pretty awesome. Here's a copy of this.

The Monitor
=========

You'd need a minimal "monitor" to start with — something that would let you enter in some binary code on an input device and jump to it. Here's a C version that lets you enter code in octal:

    typedef void (*function)();
    char program[32];
    int main() {
      char *t = program;
      unsigned i, n;
      for (;;) {
        for (i = 3; i; i--) {
          n = getch() - '0';
          if (n > 7) (*(function)program)();
          *t = *t * 8 + n;
        }
        t++;
      }
    }

Translate that into 8086 machine code with a BIOS call for `getch()`, put it on the boot sector of the floppy, and you're golden. GCC compiles it into 12 instructions, plus the function prologue for `main()`. I think that would be 32 bytes in 16-bit mode. (Maybe the BIOS call would push it a couple of bytes over.) (I don't actually remember if the alt-keypad thing that lets you type arbitrary bytes is in the BIOS. If so, you could probably simplify the minimal monitor program above by removing the loop.)

Traditionally a monitor like this was first built into the hardware, and a little later as software in ROM. If you want to use it for more than a very short period of time, it needs at least a few more features:

- the ability to correct keyboard errors;
- the ability to see what you're typing (or does the BIOS have a call for `getche`?);
- the ability to display the contents of memory;
- the ability to change the address at which new bytes will be put into memory;
- the ability to install themselves at some interrupt vector so that you can return to them when your program hits an infinite loop;

So your first task would be to write a more full-featured monitor program, on paper if possible — otherwise carve it into the desk surface with some removed part of the computer — and then *very carefully* type it in. Your second version, with a backspace, might be 40 bytes or so; you now need to type in 120 octal digits without making a single error, followed by some character that isn't an octal digit. If you do this correctly, you are rewarded by seeing your new program come to life!

Your next task is to enhance your monitor program to be truly usable, by adding the rest of the features listed above. And then you want to find a way to write it to the floppy drive.

At this point you are hoping that this is a 5¼" floppy drive so you can cut a couple of holes to make the disk into a "flippy": there's a substantial chance you're going to make a mistake and screw up writing your first boot sector, and if you do that, you're out of luck for the rest of your prison term.

So you write a call to the BIOS disk I/O routine, use it to write your new monitor program to the disk (hopefully on the back side of the disk), hold your breath, and test it.

Now you write another disk I/O routine that checks its argument to make sure it's not writing to the boot sector (or the original boot sector, which is at a different apparent location with the disk backwards) and start your system in earnest.

Edit: fixed two bugs in initial monitor code. Man, I would be so fucked if I were really in this situation.

The Assembler
===========

Your next task is to write an assembler, in memory, using your monitor. It doesn't have to be a fancy assembler with luxuries like multi-character mnemonics, the full instruction set, and stuff like that; it just needs to be an improvement over typing in x86 code in octal. Single-letter case-sensitive mnemonics for 25 or 30 opcodes, plus the ability to calculate jump offsets, are probably plenty to get to the next step. Save your assembler to the floppy in an unused sector. (You should be keeping a map of what's in what sectors, carved into the desk if necessary.)

This is also about the time you want to enhance your monitor program to show you the contents of registers and to be able to single-step.

At this point you have achieved your original goal of being able to implement Tetris or Freecell. The next step after here is roughly as hard as implementing one of these games in this impoverished assembler, so it isn't practical merely as a step toward that goal. But if you want to get to an operating system with a graphical user interface, read on.

A Low-Level Language: Forth
======================

Your next task is to bring up some kind of Forth, using your assembler. You can implement the basic primitives for a fairly reasonable Forth in about 200 instructions and 400 bytes of machine code, but that doesn't give you a text interpreter; that's another few hundred instructions. You can test each routine from your monitor program as you write it. (I have an [incomplete token-threaded Forth](http://github.com/kragen/tokthr) in 399 bytes of machine code, and a [complete self-compiling Forth compiler](http://github.com/kragen/stoneknifeforth) in 66 lines of code.)

Now you want to enhance your monitor program once more: you'll only be using it at boot time from now on, so you add a command to load and run a sector from elsewhere on the disk, so you can reboot more easily. You're going to be rebooting a lot, because every time you write a program that overwrites the wrong parts of memory, the machine is going to crash.

So at this point you've written somewhere around a thousand lines of code, which sounds like you ought to be able to do it in a day or two, but if you're like me, it's probably really more like two weeks because of the amount of effort involved in figuring out what went wrong each time you have a bug. And you're on the verge of having a usable programming environment: Forth has replaced your primitive assembler and monitor as your user interface of choice, you it can pretty easily be extended to loading programs from parts of the floppy disk, and now you probably want to implement some kind of minimal filesystem so that you don't accidentally overwrite your Forth operating system. It doesn't have to support fancy features like files that aren't contiguous on disk, files whose length isn't an exact number of sectors, nonsequential access, altering existing files, or multiple directories. It just has to keep you from accidentally overwriting data you meant to keep.

Now you probably want to write some utility programs: something to delete a file, something to defrag the disk, something to make a copy of a file, something to list the files on the disk, something to make a new version of a file. Also, you're probably becoming frustrated with waiting for the floppy disk to read and write data, so you probably want to implement LZW and huffman coding so that you can compress your files for speed. Also, you're going to have a hard time fitting the source code for an OS with a full-featured GUI on a single floppy disk without compressing it.

You can also very easily write a much more full-featured assembler now as a Forth vocabulary. Implementing your assembler as a Forth vocabulary magically gives your assembler macros and compile-time evaluation. You probably also want to write a disassembler now for debugging purposes.

You probably want a text editor now, with features like insert and delete, instead of poking strings of bytes into memory locations that contain your source code.

Protected Mode and a Memory-Safe Language
==================================

By this time, you probably want to be in 32-bit protected mode, unless the machine is so old that it doesn't support it or doesn't have more than a few hundred K of memory. Programming the x86 in 16-bit real mode is a pain; you have these constant tradeoffs between performance and imposing arbitrary limitations on data structure size.

The downside of this is that all the machine code you've written up to now won't work any more. Hopefully you can alter your Forth assembler to generate 32-bit code, and generate a 32-bit version of your Forth from a Forth version of its source code.

Your next problem is probably to implement a memory-safe language, so you can stop spending so much time tracking down pointer errors. This is probably easier to do by implementing a dynamically-typed language like Lua than by implementing a statically-typed language that's advanced enough to be pleasant to use like OCaml. You might be able to do this by implementing a memory-safe vocabulary in Forth, but I've never heard of anyone doing this.

Alternatively, you could implement fancier syntax for an unsafe low-level language first, in the manner of C. You probably want to use [PEGS](http://github.com/kragen/peg-bootstrap "parsing expression grammars"), because you can implement a parser generator for those in under a hundred lines of code, and they're roughly as powerful for commonly-used languages as LALR parsers.

Given the constraint of a single floppy disk, you probably want to compile all of this stuff into memory from a minimal bootstrapping interpreter at boot time, rather than compiling source code and storing the compiled results. (I'm assuming you have several times as much memory as floppy-disk space.)

Graphics
======

At this point you want to do graphics. Set the graphics mode to 640×480×16 via the BIOS, implement some graphics primitives by writing to the frame buffer, interface to the mouse so you can point at stuff on the screen easily, copy the font out of the VGA ROM, and implement a simple windowing system, a graphical text editor, and your games.

How does that sound? Remember the Macintosh guys did this stuff, without having seen it done before, on a 128kiB machine, mostly in assembly, in 1977–1983.

Postscript three years later
======================

Apparently this comment ended up at the top of /r/bestof today, so I guess I should link to the other stuff since then that's relevant: In 2011, I wrote a post about [bootstrapping from COPY CON](http://lists.canonical.org/pipermail/kragen-hacks/2011-April/000519.html), with some of these stages actually written in assembly and tested in DOSbox; Dave Long thoroughly one-upped that with [bootstrapping from ECHO](http://lists.canonical.org/pipermail/kragen-discuss/2011-April/001156.html), and found Greg Alt's [scheme-from-scratch](http://code.google.com/p/scheme-from-scratch/); later I tried [bootstrapping an interactive text editor starting from a noninteractive Lua interpreter](http://lists.canonical.org/pipermail/kragen-discuss/2011-June/001168.html), and then this year, Dave wrote a ["tweetable" "symbolic" hex COM loader](http://lists.canonical.org/pipermail/kragen-discuss/2012-May/001234.html), which is sort of like an assembler without mnemonics, in 140 bytes of machine code.

If you're interested in participating in the blog-like mailing lists where I post that kind of stuff, check out the [subscription page](http://lists.canonical.org/mailman/listinfo/).

Happy hacking!

A way to clean a Visual Studio 2012 solution.

I have a solution that I would like trimmed down to the bare essentials; here is my idea I'm going to test.

Copy the entire the Visual Studio solution (projects, junk, and all) into two full copies one per folder.
Example: "SolutionA" and "SolutionB". The goal here is to have TWO working copies of the real solution.

Disclaimer: You are responsible for your own action.

Load up solutionA, and use Resharper (or any other similar program) to "Format/Clean" the source code. All files. Make them formatted your "not normal" way, then your normal/approved way.

The idea here is to induce changes. Change each projects settings around. Then change them back to 'correct'. Induce the most changes you can think of, although make sure each project can still build and pass unit testing.

Find a duplicate file remover that will scan file CRC (or even byte by byte). Let it find all duplicate files between SolutionA and SolutionB.

Then remove all duplicate files found under the SolutionA folders that you feel comfortable removing.

Test the build!

If everything is okay, you should have a slimmed down version of your projects.

Notice: Your results may vary. Let me know what worked.

Async/Await FAQ - .NET Parallel Programming - Site Home - MSDN Blogs

Async/Await FAQ - .NET Parallel Programming - Site Home - MSDN Blogs:

C#: Thread Safe Generic List

Since so many people seem to be requesting a thread safe generic List in C#, here is my implementation:

Download link: "ThreadSafeList.cs"

---

Why C# Is Not My Favorite Programming Language

Why C# Is Not My Favorite Programming Language:

What a bunch of blarg...I love C#. I don't want to make my points by attacking the author personally, but the page is so full of "BS".

1. Default Object Lifetime Is Non-Deterministic

It is not supposed to be deterministic! It is this way on purpose so we can focus on what we want to do rather than worry about allocating and deallocating memory. Only a control freak would want to control every byte used.
The example 'AutoLock' class as shown does not let you control when the lock is Unlocked. The lock() functionality in C# provides way better scoping.

 I am supposed to remember to use using, or litter my code with finally blocks.
Um, YES... Using the language correctly will work wonders.

2. Object Lifetime is Not Determined by Scope
Lol. Not even going to honor this inaneness.

3. Every Function Must Be A Method
I repeat "Object Oriented". Why would you want a global non-namespaced function called "Sin"? Can you understand why that would be so bad? Btw, learn about C# extensions if you don't like the taste of this sugar.

4. Containers Have Algorithms As Methods
See my response to #2.

5. Default Comparison Behavior Is Dangerous

Dangerous? No. Gotcha-inducing, yes. When you don't pay attention to what you really intend to compare. Btw, I think the most Vector 'classes' are actually structs.. anywho...


6. Operator Overloading Is Severely Broken
Only when you implement it wrong.

Conclusion: for someone so smart, you really need to grok C# and use it the correct way.

Using Extension Methods and the Win32 API to Efficiently Enumerate the File System « Tom’s Blog

Using Extension Methods and the Win32 API to Efficiently Enumerate the File System « Tom’s Blog: Very nicely written.

BerliosProject:NHI1 - TheCompiler - OpenFacts2

BerliosProject:NHI1 - TheCompiler - OpenFacts2: "Better Programming languages lead to more, larger and more complex software."

Wrong and wrong.

Bad [lazy] programmers lead to more complex software.

And complexity in itself is not a bad thing when logically organized well.

Clamping Efficiency

Been poking around the XNA 4.0 framework, trying to figure out it all works together.
(I finally realized that Vector3 themselves are not absolute positions in a 3D spatial volume, but rather relative values until Transformed to absolutes. Right?)

I came across this line of code in an example: turnAmount = MathHelper.Clamp( turnAmount, -1, 1 );
So I dug into the Clamp function.

What I saw was this:

public static float Clamp(float value, float min, float max) {
      value = (double) value > (double) max ? max : value;
      value = (double) value < (double) min ? min : value;
      return value;
    }

Isn't this function possibly inefficient? First of all, it is casting the floats to doubles.
Why? Does the compiler ignore this 'feature' and optimize it away?

And also, if the value is between the min and max, it ends up setting the value to value.
Why? Does the compiler ignore this 'feature' and optimize it away?

I would change this Clamp function to this:

public static float Clamp( float value, float min, float max ) {
            return value > max ? max : ( value < min ? min : value );
        }

If these functions are used even once per Game.Update(), and that Game.Update is called at 60 times per second.. and each Model might use it..

I'm sure the efficiency could add up to a better performing game.

XNA oddity with VertexPositionNormalColored

Getting my feet wet on the XNA 4.0 framework.
Going along on the tutorial over at Reimers.

When I got to the lighting section, my game form started going blank.
No errors, just a big black background.

So after many (many) recopies and re-pastes from the webpage, I narrowed down the silent bug to the ordering of the fields of the struct "VertexPositionNormalColored" (which inherits from the interface "IVertexType") Position, Color, and Normal.

Here is the corrected version that doesn't go funky:


        [ StructLayout( LayoutKind.Explicit ) ]
        public struct VertexPositionNormalColored : IVertexType {
            public static readonly int SizeInBytes = 28;

            public static readonly VertexDeclaration VertexDeclaration =
                new VertexDeclaration( new[] {
                    new VertexElement( 0, VertexElementFormat.Vector3, VertexElementUsage.Position, 0 ),
                    new VertexElement( sizeof ( float ) * 3, VertexElementFormat.Color, VertexElementUsage.Color, 0 ),
                    new VertexElement( sizeof ( float ) * 4, VertexElementFormat.Vector3, VertexElementUsage.Normal, 0 )
                } );

            [ FieldOffset( 0 ) ]
            public Vector3 Position;

            [ FieldOffset( 12 ) ]
            public Color Color;

            [ FieldOffset( 16 ) ]
            public Vector3 Normal;

            public VertexPositionNormalColored( Vector3 p, Vector3 n, Color c ) {
                this.Position = p;
                this.Normal = n;
                this.Color = c;
            }

            VertexDeclaration IVertexType.VertexDeclaration { get { return VertexDeclaration; } }
        }

"Programming" versus "Coding"

Reposted for posterity with a linkback.

Coding is about how you should write,
Programming is about how you SHOULDN'T!

Coding as about the Language and Syntax,
Programming is about the Paradigm, the Thought Process

Coding is represented by the 'Writing' Metaphor,
Programming is epitomized by the 'Construction' metaphor

Coding defines the Solution,
Programming defines the Problem too!

Coding creates the Implementation,
Programming creates the Interface

Coding is about "Getting it done...",
Programming is about "Getting to know it!"

Coding gets you Paid,
Programming makes you Satisfied.

Coding is what we HAVE to do,
Programming is what we SHOULD be doing!

C#.NET Script – Associative Array | Xhanch Studio

C#.NET Script – Associative Array | Xhanch Studio: " http://xhanch.com/" I don't understand why this class simply wraps a dictionary.. I don't get it.

What am I missing?

Crossword Puzzle Generator in C#

Crossword Puzzle Generator – in C# — Pierich Consulting:

My comment on a comment in the code on that site: "// This next line is a hack that just makes the code work."

When I see comments like that I just have to /shudder.