That Feeling When... run into compiler bugs that prevent successfully compiling your library...

While testing some advanced features of the parsing library in preparation for the next step toward building causerie, this is exactly what happened: an obscure bug with the Free Pascal runtime that seems to defy debugging with GDB and which crashes the program every time it runs. (If you're really interested to know, it seems to have something to do with the way that TObject handles memory allocation).

It's proven to be a rather large setback for causerie, but it isn't the end of the world. I was already developing a C interface for the libraries, to make them as portable as possible, and if all else fails I can expand upon that to take the whole thing into C. I'll have more information here soon.

Writing a Command-Line Parser, Part 2

Previously: Writing a Command-Line Parser, Part 1

In the previous article, we defined the basic elements that are required in order to produce a parser: tokens, opcodes, the general language syntax, statements, expressions, and symbols. Tokens and opcodes are fairly similar across parser implementations, typically differing only in the types of characters allowed to be part of a token and in the data type used to represent the corresponding opcode. The next item that must be addressed, then, is the syntax of LinearC, our command-line argument "language". The syntax will inform the opcodes used and the types of statement and expression handlers we must define. It will also help the tokenizer to correctly classify the tokens read from the command line. Continue reading...

Writing a Command-Line Parser, Part 1

As with other compilers, causerie will need to accept a variety of command-line arguments from the user, or from make on behalf of the user. This necessity provides with an excellent opportunity to test and fine-tune the base libraries before we tackle the more complex task of parsing a full-fledged computer language.

Why use command-line arguments at all? Unless you have written a very simple program, it is likely that you will want some way to adjust the behavior of your code based on some event or circumstance which you cannot know at the time the program is compiled. You could try to make a list of such circumstances and try to compile an iteration of your code for each one of them, but that entails a high degree of effort which is largely wasteful, since it is simpler to allow the user of your code to indicate what behaviors are desired. Command-line arguments provide a way to do this, as do configuration files, but command-line arguments take up less space and are more portable, since they do not require an additional file besides the executable itself. Since simplicity is one of causerie's goals, we will use command-line arguments instead of a separate configuration file.

Causerie's parsing design is flexible enough that it can be adapted to other uses, such as parsing command-line arguments; thus, while there are libraries already available for this purpose, such as the getops unit that comes as part of Free Pascal's runtime library, utilizing the libraries we already have for a simple case like parsing command-line arguments will allow us to find bugs and ensure that the parser can handle a more complex task. Continue reading...

Implementing AutoCorrect in JavaScript

Although I like PmWiki and BlogIt for their simplicity, I sometimes miss a feature or two from the content-management software I developed. I prefer using Markdown to Wiki syntax when writing posts, and fortunately there's a recipe for that. There is no recipe (as of this writing) for the second feature I miss: auto-correct. The software I wrote would replace various combinations of characters with nicer-looking replacements – such as (R) with ®, (C) with ©, straight quotes with curly quotes, etc. Maybe I've just been spoiled by the implementation of the feature in LibreOffice, but having to look at straight quotes and uncorrected copyright symbols seems a little jarring. I mean, if the technology exists to make your text beautiful, why not use it wherever it can be used?

It has occurred to me that I could simply rewrite my original software to be more like PmWiki: to use the file system instead of a database while retaining the features that I want. But, since my free time is limited, my primary focus remains on writing a computer language and then a game engine. It was quicker to write a post-processing script that would run after each page on the site loads, subtly tweaking the items that needed to be adjusted until the page looked the way I wanted it to look. Continue reading...

Causerie: Progress

It's been several months, but progress on the language continues! Documentation for the base library is now online, and there is a wiki for the language itself.

The first iteration of the base library (and the rest of the code) is written using Free Pascal. The library provides a solid foundation for what comes next: the parsing library, which I'm working on now. Once the parsing library is finished, we can get into the code that will be used to process the language itself.

But, of course, to do that, we need to have a solid grasp of what the language is! This is the purpose of the causerie wiki, where the language specification itself will be hammered out and finalized. There you can see the various ideas and iterations of the language definition, and there will eventually be example code and a lot more!

There is more to come, of course, so stay tuned!