Corey Ogburn

Earlier today I put up a page explaining how a particular esoteric programming language works, as well as my interpreter for it. Brainfuck is not simply a name, but also an accurate description of what it takes to fully understand what the code is trying to accomplish. Given only eight symbols, this language is turing complete. This means that the language can accurately simulate any turing machine... i.e. executing under a defined set of rules, any computer algorithm can be completed. I've messed around with the language a bit and it is as its name suggests. In order to add two numbers together and display the result, you need to go through a command along the lines of "[->+<]>." where the number you started on was one cell to the left of the number you added it to. It proceeds by subtracting one from the left number and adding one to the right number until the left number is zero. If addition takes six commands, imagine what multiplication would take, nevertheless exponents or square roots. However complicated these commands might be, this language is capable.

I have yet to think of a good application for this language as opposed to other languages. I found myself asking why it was even created. To borrow a line from Wikipedia, it was designed to be a turing machine with the smallest possible compiler. Some people have been as efficient as to write a compiler that is only 200 bytes in size! Attached to the page is my version of an interpreter for this language. Although not nearly as small as 200 bytes, my interpreter comes with a few extra features than simply running the commands. As best as I can find, mine is the only one to let you type in a numerical byte instead of just a character off the keyboard. I hope I'm not the only one who finds this a good idea... Regardless, I also added in some switches to output particular information to files; information such as routing all output to a file and a memory dump of the stream that the command generated while it was being run. Source code and all is available in the article.

Project, Source Code brainfuck, interpreter

I did an article over threads in a command line project. In a command line project, there are less complications than it's GUI alternative. Here, I hope to go into enough detail to put to rest the confusion that threads can introduce to a GUI application. The big hurdle is around the limitation that the only thread to interact with a control is the thread that created the control. In the beginning, I saw this as a silly rule, one not worthy of throwing an exception.  The more and more I use threads, the more obvious it becomes that this is less of a suggestion and more of a golden rule. So, the question begs, how do we create a thread to do something that we need a result back from? How do we get any information from a thread that's been started, such as progress, or state of operation? With callbacks, events, and the Invoke method! If we take some of the concepts I discussed in threaded CLR projects, like a payload struct, and use them here, than this will be an easy concept for you.

To start, I'll say that there is a long-named boolean variable we can set to false in the constructor of a form called "CheckForIllegalCrossThreadCalls." When set to false, is does just what you think, it will not check for illegal cross thread calls. To break down what that means, when true it will check to see if a thread tries to access a control it did not create, and when false, it will allow it. In simple applications this may be all you need, but any amount of complexity and it quickly becomes a bad idea. The problem with threads is their unpredictability. Should two threads happen to be editing the same control, things become unstable. From unintended outputs to crashing programs, it's not something you want to test, it's just better to do it right the first time, and every time. This variable, CheckForIllegalCrossThreadCalls, should remain true, by default it is.

For my little example here, the UI will consist of two progress bars and a button. Upon clicking the button, one thread starts per progress bar and they will update the progress bar they're associated with over time. This will leave the GUI thread to do nothing, at least until each thread calls their invokes. In addition to these controls, the form will have two delegates, two events, and a list of all the running threads. The events and delegates are paired. One pair is to update a progress bar, the other pair is for when a thread completes. There is also a struct to act as the payload for the threads, as defined here:

More...

Advice, C#, Development, Source Code invoke, threads, windows message queue, GUI

Threads... I'm not going to claim to be an expert at explaining all the low level happenings or all the intricate little bugs and/or features of them. I am going to be talking about good foundation code for making threads work right without worrying about races, locks, or GUI halts. First, a basic understanding of what a thread is. A thread allows for multiple lines of execution to be running in one application at the same time. You may need this for many different reasons. With only one thread, that thread is in charge of what's called the message loop. It'll listen and respond to events such as repainting the form and user interactions (clicking a button, dragging the window), if you put that thread to use doing something that takes a lot of time (say you click a button and that does a lot of network traffic or image processing), then the message loop goes unattended, this is how Windows decides if an app is "Not Responding" (when the message loop accumulates events) until it completes whatever it's doing, then it begins responding to the message loop again. With another thread, you can handle the heavy load and the original thread can continue responding to events in the message loop. This can be both a good thing and a bad thing.

There are many problems that can arise in multi-threaded application. Let's say you had an array, and in one thread you're getting element 6 in that array and in another array you're inserting an element into index 2. Different things could happen based on which thread gets there first, and it's impossible to tell which will. You can always use a lock statement to prevent data corruption due to multiple threads accessing it, but that can lead to thread locks and isn't always the easiest thing to do. Instead, design your application to be thread safe from the ground up. It's easier to hammer out the details to a thread safe app first and then implement it than it is to design a semi-working app and fix the thread issues once they've become prevalent. Defining set rules for how to be thread safe is hard. The knowledge comes with experience in many different applications.

More...

Advice, C#, Development, Source Code thread, delegate, event, lock, concurrency

Windows Presentation Forms (WPF) brought a lot of cool features to C#. Hardware accelerated rendering, XAML backed control layout, and more versatile ways to bind your data to your controls. In WinForms there were ways to bind data base schemes to controls, but all in all it was a pain and rather limited. WPF opens up binding to almost any type. If you don't know what binding is, binding is when a particular property is "bound" to a control such that when the value changes, the control is updated, and in some cases, if the control is changed, the property is updated. I've thrown together a very basic application to help demonstrate some of the basics of binding, let me walk you through it.

More...

C#, Development, Source Code binding, wpf

The Singleton Pattern is one of the more useful design patterns I've run across. Not because it can be used everywhere, it actually has very few applications where it's needed, BUT when it can be applied it makes things so much easier. Sometimes you just need one instance of a class for the lifetime of the application, but you might need that instance in a large variety of locations in your code, such as if you had a class with a connection to a file, another computer or a database but in several different places in your project you need that connection. Without this pattern, you either elevate the scope of that instance to a global status or you pass the instance to every method that needs it, leading to complications about having it available in methods that don't need it, e.g. if your main method calls methodA, methodA calls methodB, and methodB needs this instance, you'll have to pass it through methodA that doesn't need it. So what's the answer? How can an instance be accessible anywhere without losing control of the scope? The Singleton Pattern is how!!! Simple to implement, a Singleton Pattern entails changing only a few things to a normal class. All you have to do is make the constructor private and provide a public static method, traditionally named GetInstance(), and it either makes the first instance, or it returns that instance.

More...

Design Pattern, Source Code design pattern, singleton, multiton

From Wikipedia: In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. Design patterns can be a touchy subject. Sometimes described as "a solution seeking a problem," they can complicate projects where they have been implemented incorrectly through misunderstanding the pattern or by being applied to a situation that doesn't warrant that design pattern. With that said, take this article with a grain of salt. Don't look for a place to use it, but keep it as a tool for when a problem that may need it arises. With that disclaimer behind me, let me introduce you all to the Observer Pattern.

More...

C#, Design Pattern, Development, Source Code example, design, observer, pattern

My first post about this covered some really basic material. Here, I'm going to talk about a few features that I've recently learned about or started using. Remember, the more you can have your IDE do for you, the better you can spend your time on what's really important.

More...

Development, Source Code VisualStudio, Features

I'm going to begin putting up some of my projects for you all to read, run, and use. First up, Wrapfield! A twist on the traditional click and flag game, Minesweeper has been taken to a new level with a new rule alongside all the original features. Take the code, learn from it, play the game, do what you want to do, but of course I ask you leave my name (and my buddy's name, Shawn) left in the about dialog box. You can find it on the right hand side under Pages or by clicking here.

More projects are on the way as I clean them up and prepare them for the site, although not all will contain source code such as this one. Also, I want to begin writing multi-part case studies where we walk together through complex projects facing decisions, possible fixes and their flaws, as well the optimal solutions for those problems. With complete access to the source code of the final project, and all the reasons behind the code as the project expands. Keep an eye out over the coming weeks as more projects and these case studies come to the site. Have a particular idea for a case study? Propose the idea in the comments, if I like it I may use it!

C#, Project, Source Code source code, minesweeper, wrapfield