Software Development

Charles Babbage broke the autokey cipher in secret, and several years later, Kasiski accomplished the same feat in 1863. Looking online, I could not find any substantial descriptions as to how this was done (and there seems to be some confusion as to exactly WHICH variant Kasiski broke). I originally thought that many cryptographic algorithms were complex and difficult to understand. Not so. They are actually very simple.

The Vigenère cipher comes in many different flavours. There are the autokey variants as well as the Quagmire variants. A simple explanation can be found here.

Read more...

I've had a request to see component interface creation, so here it is.

WARNING: This release does nothing. Really!

You may consider this my version of the black triangle.

It just shows Project V component interface creation and deletion. This will change in the near future since an interface is supposed to be global, but using that interface needs an instance (or at least a way to reference each use of that interface). Right now, there is no difference. Then again, I may simply leave instances without a name since only the user needs it (the compiler can already tell the difference). If the user wants to name it, they can. (Thinking out loud here.)

The type editor (left pane) is still disabled because there's a bug in it and I haven't gotten to fixing it yet.

Oh, and this is just the tip of the iceberg. The Project V type system is fully operational as is the compiler. The runtime engine will need some tweaking, but again, this is all code that has no visual counterpart.

Have fun!

Requires DirectX 9.0c (vs 1.1+, ps 1.4+, 32MB+ video RAM)

Project V Install (4MB)
Mirror #1

I was reading on reddit, and other places, and saw a few comments on project size. One person said that 30K was approaching a large project. Is this still the metric?

<5,000 line = small project
~50,000 lines = medium project
>100,000 lines = large project

I could write 100,000 if I wanted to, but I always try to keep it small.

Project V is now topping 42,000 lines (this includes blanks and comments, reduce by 20% to get code only). And I have over 30,000 more lines of throwaway code. By the above scale, Project V is a "medium" project. Luckily, it still feels like a small project.

The breakdown is about 15,000 lines for the GUI (mostly visual components). The setup phase and resource handling take about 7,000 lines of code. And the type system for Project V takes roughly 10,000 lines of code. The other 10,000 lines are mostly support code like RNG's, font instance implementations for ICU, interface implementation for texture manipulation, stuff like that.

What I find strange is that the type system takes that much code. Most of it isn't even about the type system itself. It's just about handling sets and nodes. The core type system itself is a mere 574 lines. This file handles type and value comparisons. But I should mention that I have a lot more "glue" code that most other projects, especially in the type system. I don't just rely on what the language has provided.

Project V has 35 cpp files at this point.

I know I will reach 50,000 lines in a month's time since I'm going to be coding up Project V components and the runtime. So I will officially be heanding into "large" project land soon. Like I said, I try and keep the "small" project feel. And I believe I've more than succeeded with Project V.

What are your thoughts on project size? Does it affect anything? For me, nothing has changed because I've built projects this size before. Well, perhaps not 50,000 lines, but in the tens of thousands anyhow. So I started the framework with the intention and knowledge that it would get this big. Not only that, but I consider these to be proper software development practices. I've mentioned these in the past such as helper objects, separating different modules and including plugin mechanisms.

In the past, for me, a large project meant one that suffered under its own weight. Where you could feel its bulk getting in the way of contributing to the project. These were rather large projects. Close to a million lines. Sometimes well over that if you consider satellite projects. I'm not sure this is necessary anymore.

Another update on Project V. I'm done events. This was a really ugly and intrusive change. It's one of those things that I rant against. I did it as cleanly as I could and implemented in the way I've mentioned in the past to keep two versions of the code accessible. One version triggers an event. The other does not. The reason for this is that member functions often want to do modifications without triggering events mid-way through. So the no event methods come in handy.

This is one of the things that really does not work anything like the real world. In real life, you can have someone watch the entity in question, and if it changes, the person can report back with that change. Or you can simply have a device do the work for you.

On the other hand, with memory you can't just monitor a memory location. In theory you could, but it'd be awfully inefficient. The processor can tell when a 4K (or 1MB) page has been written to. This is necessary for virtual memory. Certain memory profilers on Linux use this method as well to know if your memory has been corrupted or if you have any bad pointers. But allocating 4K (or 1MB) for each object is ridiculous.

What I have to do is actually insert some code before and after the changes take place. For the events that get called right away, I have imposed a restriction that you may not modify the entity in question within the event handler. However, delayed event handlers may do whatever they like.

IOW, immediate event handlers are for monitoring purposes only. Delayed event handlers are used if you need to update the component network itself.

I think this is a good compromise and ensures that there are no recursive event triggers.

Another problem I encountered was deletion of entities within the component network. I don't want to trigger events and then find out that entity in question isn't even around anymore. Actually, this is what made me consider delayed events in the first place. Not only delayed events, but delayed deletion. Deletion will do everything you would think. It separates itself from any other nodes and triggers all the events that these actions would generate. But it doesn't actually delete the node itself. So all events will at least get access to the entity itself which includes its name and ID. Once all delayed events have been handled, all items queued for deletion are deleted.

And yes, I'm well aware that this is one case where GC would have been helpful. But I don't want to be dependent on a GC when I build the native compiler. It's simply not necessary.

Next up on the agenda is completing the building of networks. I've had most of the code done for a while now. But with events, I can keep the GUI automatically updated of any changes. This is what was slowing me down. I did not want to have to tell the GUI of every change. How am I supposed to know what GUI components require updates? Instead, GUI components register an event handler within the Project V component network. That way, each GUI component will be in charge of keeping itself updated. Much cleaner and much easier to maintain. Also reduces coupling between GUI components and the Project V component network.

(Note that GUI components are visual like buttons and Project V components are computational nodes like addition).

After I can build networks, I'll built the single core runtime engine which is already done. I just have to update a few things on it to reflect the changes I've made since then.

Then multicore runtime engine... then distributed runtime engine... then the WORLD!

I'm getting closer to finishing events in Project V and although I will simply have built-in components to start, I am starting to think about how to represent different operations when I get to executing them natively. When do different operations actually represent the exact same operation?

For example, in video cards, we render one texture at a certain location to essentially copy one texture into an (x,y) location in another (the backbuffer). Leaving out 3D operations for the moment, isn't this really just an array copy? How would a generic operation be described?

Read more...