Python Script for Splitting a Delimited File Into Multiple Files

I needed to split a big file delimited by double line breaks into a series of smaller files. Python to the rescue!

Posting this because I didn't find anything on google that put together all the pieces I needed.

def split_file_on_delim(to_split_name, delim, splitted_base, splitted_ext):
    """This function reads a file, splits on delim, and writes each chunk out to its own new file."""   
    fn = open(to_split_name, "r")
    fr = fn.read()
    fs = fr.split(delim)
    for i, chunk in enumerate(fs):
        fw = open(splitted_base + "_%i." %i + splitted_ext,'w')
        fw.write (chunk)
        fw.close() 

#sample usage:  

split_file_on_delim("c:\\tmp\\to_split.txt", "\n\n", "c:\\tmp\\splitted", "txt")

The Mythical Man-Month: A Review

Here's a link to my review of The Mythical Man-Month, by Frederick P. Brooks, Jr. I've been meaning to write one for a while and just now got around to it. Cross-posting here since it's related to programming.

Cities and Programs

Rome was not built in a day;
Neither is a complex program.

Both might have twisted, turning, needless complexities,
And yet the program is much more easily mended
Than the living, breathing, cobblestoned city.

Both can have hasty, ill-advised, poorly considered changes
(That often prove disastrous)
And sometimes work more by accident than by design.

Both ultimately devolve into disuse and ruin,
Living on in the memory of fewer and fewer
Until at long last, the last rememberer's long life
Is snuffed
softly
out.

A Software Engineer's Hippocratic Oath

I ran across this interesting article by Phillip A. Laplante on the responsibilities of software developers. More than a decade after it was written, many of Laplante's ideas and observations still ring true.

Here's his proposed version of the Hippocratic oath for software engineers. Even if it never becomes a part of the sacred and occult investment rites¹ which every developer must undergo, it contains a lot of truth.

I solemnly pledge, first, to do no harm to the software entrusted to me; to not knowingly adopt any harmful practice, nor to adopt any practice or tool that I do not fully understand. With fervor, I promise to abstain from whatever is deleterious and mischievous. I will do all in my power to expand my skills and understanding, and will maintain and elevate the standard of my profession. With loyalty will I endeavor to aid the stakeholders, to hold in confidence all information that comes to my knowledge in the practice of my calling, and to devote myself to the welfare of the project committed to my care.

I especially like the idea of developer as a steward of things that have been entrusted to her for a time. After all, isn't that what most of our lives are about anyway?


¹ Which I just now realized I probably shouldn't have even mentioned in so public a forum as this here Internet Web Log is. Whoops! Sorry, Programmer Illuminati.

Error Creating Form: Ancestor for 'TFormName' Not Found

So, this one has been bugging me for a while. I'm using Embarcadero's RAD Studio 10 Seattle, working on a sizable C++ application. For a few specific units, whenever I load them, I get the following message:

Error creating form: Ancestor for 'TFormName' not found.

(Of course, it actually said the name of my form, not 'TFormName'.)

And when this happens, my .dfm (Delphi Form) won't load, so I can't do anything with the design of that particular form. To work around this, I had to open the ancestor (or in at least one case, multiple ancestors), and leave them open in the IDE, before being able to view my form's .dfm at all.

So I double-checked all my include and lib paths, as well as my include statements in the headers of my .h files. I googled my fingers to the bone, looking for any answer I could find. Nothing.

Finally, I noticed that the form I was trying to inherit from wasn't even in the inheritable items list, which led me to this old post, and I knew I'd found the culprit.

In the end, the solution was spectacularly simple: Remove all problematic units from the project. Then, add them back in the appropriate order. No more error!

It really was as simple as this:

Solved: Unable to open file 'FIREDAC.STAN.FACTORY.OBJ'

Today, I kept getting this error in Embarcadero C++ Builder XE6 when trying to compile a pretty large project:

[ilink32 Error] Fatal: Unable to open file 'FIREDAC.STAN.FACTORY.OBJ'

My project referred to a library that had FireDAC components, though I wasn't using any of them. My project uses DBX, not FireDAC, and VCL instead of FMX.

FireDAC.lib was in the project includes in my .cbproj file, so I had no idea what was wrong.

I finally found a fix: drop a FireDAC component (I used FDConnection) on a form. Save all, compile, and it worked. Then, I just deleted the FDConnection from the form and I was good to go.

Changing Fire Monkey (FMX) TextSettings at Run Time

One of my beefs with Embarcadero's C++ Builder is that it is so hard to find decent documentation or tutorials on how to do even the simplest things with their visual tools. This is especially true if you're developing in C++ instead of Delphi.

I experienced a pretty steep learning curve with Embarcadero's Visual Class Library (VCL) -- not because it is especially complicated, but because I couldn't find much good documentation for it.

Right now, I am building an FMX application, which is similar in a lot of ways to VCL. However, one thing has changed a lot: the styles are now driven by stylesheets.

For example, in VCL, it was relatively easy to change the font attributes of dynamically created elements at run time. Not so with FMX.

After several hours of fruitless googling, I still haven't figured out how to change my StyleLookup for a dynamically created TEdit. My custom style works fine for controls created at design time, but I'm apparently missing something from the picture.

After some trial and error, I did manage to come up with a solution that pretty closely replicates how text formatting worked in VCL. This obviously isn't ideal, but at this point, I will take what I can get and be happy to move on. The trick is to turn off the FontColor in your object's StyledSettings.

//Make ValueLabel to display output
TLabel * ValueLabel = new TLabel( this );
ValueLabel->Parent = VerifyMappingsScrollBox;
ValueLabel->Position->X = ValueLabelLeft;
ValueLabel->Position->Y = LabelTop;
ValueLabel->Width = ValueLabelWidth;
if ( OutputValue.Length() == 0 )
{
//Turn it light gray if empty
  ValueLabel->StyledSettings = ValueLabel->StyledSettings >> TStyledSetting::FontColor;
  ValueLabel->TextSettings->FontColor = claLightgray;
  ValueLabel->Text = "Empty";
}
else
{
  ValueLabel->Text = OutputValue;
}

So far, I'm not too impressed with the FMX framework. It does some cool things, but some elements are so buggy and counter-intuitive that it's easy to see why no one is making new documentation or tutorials for it. Which is a bummer for those of us who are obligated to use it for the foreseeable future.