Category Archives: Announcements

Post navigation

I’ve written about meetup groups in the blog space before and I continue to enjoy them as a social and educational outlet. Yesterday, I attended my first East-End Tech Meetup. I must say that having a group closer to home is a lot nicer than a 3 hour round trip into downtown Toronto. The real excitement, for me however, was the topic. Here it is from the meetup description:

A remarkable young member of our community is planning to launch a GTA-class Makerspace right here in Oshawa. He wants to present his ideas to our community, elicit feedback, generate more ideas & strategies, as well as gather the much needed support from our citizens here in the Durham Region. This is no small undertaking and it will take the effort of many to back his execution.

This would be a substantial asset to Oshawa and its people so spread the word. Tell your friends & neighbors. Every bit of support is needed to make (pun) this a reality.

Now, I’ve visited maker labs before. They were all far away, very expensive, and difficult to join, especially for an older person such as myself. Let’s just say that I did not feel welcome.

This group is different. I suppose it is at least partly the thrill of getting in on the ground floor, but there was an energy present that I had not seen or felt before. There was also an open exchange of ideas and many diverse contributions were being sought after. My impressions were very positive.

The effort is still in its infancy, but they have a facebook page. Take a look and hopefully find a resource to express your creativity through engineering and making.

Yours Truly

Peter Camilleri (aka Squidly Jones)

Share this:

Like this:

It is with great pleasure that I am finally able to announce the release the initial beta of the fOOrth programming language system version 0.5.0. This language, written entirely in pure Ruby is released both as a Ruby gem and in Source Code on github.

So, what exactly is the fOOrth programming language system anyway? The source code repository has this to say about the project:

The fOOrth language is an experimental variant of FORTH that attempts to incorporate object oriented and functional programming concepts. It also tries to extrapolate an alternate reality where FORTH was not frozen in the past, but continued to grow and develop with the times. Above all this project is the result of nearly 30 years of thought on the design of threaded compilers and languages with simplified grammars and syntax.

Also included in the docs folder are a User’s Guide and Reference in both open office and PDF formats.

A lot of work and effort has gone into this personal labour of love. For example, I have discovered that writing good documentation is a lot harder than it looks. It is certainly harder than just writing code. I have also found however that having to explain what is going on in plain, simple, and easy-to-understand terms has resulted in many improvements to the code that would not have happened otherwise. In effect, it served as a sober, detailed review of the code being generated.

This is still only a beta, and there is still a great deal more work to do. I hope you find it useful or at least interesting. If you like what you see, give the code a star to show your support. Suggestions, comments, complaints and ideas are always most welcomed.

Yours Truly

Peter Camilleri (aka Squidly Jones)

Share this:

Like this:

Just because code works, doesn’t mean it’s the correct code. A case in point is my own minitest_visible gem. This little bit of Ruby code adds simple progress tracking to the testing process. In any programming, and especially in a dynamic language like Ruby, testing is vital. So is having faith in those tests.

Now the standard minitest testing system is awesome! It is full of helpful methods for confirming the correctness of code. It is however a little terse regarding progress. That is where minitest_visible comes in. When used, it lets you know the version of minitest being used and prints out the name of each test file as it is processed.

A fairly simple task. Yet, when I came up with the first version of this code, it was clunky and ugly, but it worked. I suppose I had other matters pressing at the time, but I let things stand at “good enough”

Recently, I began to think that there must be a way to make the code better, cleaner, and easier to use. It seems that I have indeed learned some stuff in the last year because I am now writing about a new version that is far simpler and streamlined.

OK, let’s be clear: The old way of doing things is still supported, but prints out a message about the needed changes. Test still pass though so disruption and panic should be minimal.

Share this:

Like this:

Having just announced format_engine version 0.4.0, things seem to be speeding along as I now announce format_engine version 0.5.1 and ruby_sscanf version 0.1.1.

These two gems are rather tightly coupled. The ruby_sscanf gem uses the capabilities of the format_engine to create a Ruby translation of the POSIX ‘C’ sscanf routine. This allows a formatted string to be processed into the data elements contained within. The new version of the format_engine is required to add some features required by the ruby_sscanf gem.

I thought a great deal about the idea of merging the ruby_sscanf gem into the format_engine, but in the end, concluded that they did different things despite the high degree of coupling. Further, ruby_sscanf modifies (or monkey patches) the base String class, and that was something that might not always be desired. So two separate gems.

Share this:

Like this:

I am pleased to announce the new version of the format_engine gem. This blog has been highly remiss in keeping up with the releases of new code. So, we are skipping ahead from version 0.0.2 to 0.4.0. After a hiatus of six months, the new version has improvements, mostly to the parser side of the engine.

Parsed spaces may match zero or more input spaces so that it is no longer necessary to predict the exact number of spaces between data elements.

The parser now supports strings with regular expression sub-sets like %[abc] which matches the input in the set “a”, “b”, and “c”. Also supported is exclusion sub-sets like %[^abc] which matches the input not in the set “a”, “b”, and “c”.

Share this:

Like this:

In other news, a very minor bug fix for the format_engine gem (just recently released) is now available. This corrects an issue with the handling of invalid format strings. A very minor fix and most need not rush out a get the update. Still found on RubyGems and GitHub. The plus side is that as a minor bug fix, and now passing even more tests, this is a low risk upgrade.

As always, comments and suggestions are welcomed. If problems or questions are encountered, please raise an issue under the GitHub project. I do watch the issues very closely so will be sure to give any reports immediate attention.

Yours Truly

Peter Camilleri (aka Squidly Jones)

Share this:

Like this:

Just recently in my programming endeavors, I began to examine the Time class in Ruby. There were many subtle and nuanced points about how Time values were handled, but one area that struck me as interesting was how it dealt with formatted string I/O. The Time class supports two function strftime and srtptime. Both are based on “C” library time routines. The strftime method takes a time object, and a format specification string and creates a formatted output string. The strptime method reverses this with a formatted string and format specification string as input and a time object as output.

As I was considering these methods, it occurred to me that a generalized mechanism for build these sorts of formatters and parsers would be a useful thing. A check of available gems did not reveal an obvious candidate for this task, so, I set about writing my own. The format_engine gem is the result.

This code has undergone a decent amount of testing so the 0.0.1 release version should not be seen as too discouraging to those seeking to try it out. The gem may be found at Ruby Gems and the source code at GitHub.

I hope you find this code useful. If you feel motivated to comment, leave me a note. If you find a problem, please raise an issue on the project in the GitHub repository.

Yours Truly

Peter Camilleri (aka Squidly Jones)

Share this:

Like this:

A comparatively new medium for social interaction is the idea of a “meetup”. A gathering of like minded people to a public event, usually moderated by a web service like meetup.com or it’s equivalent. I attend these as a way to relax and meet interesting people.

There is however a sort of downside; Most of the people attending are 30 years younger than me. The result is this rather odd snippet of conversation:

Young Person: What do you do?
Old Guy: I’m a programmer.
Young Person: What kind of web programming do you do?
Old Guy: I do embedded systems programming.
Young Person: Huh?

From there the conversations diverge a lot, but the problem is answering the difficult question always follows: What is an embedded system?

While Wikipedia has an excellent article on this subject, I’ll give you my answer to this question:

An embedded (computer) system is a computer that is part of a product, device, or system that is not itself considered to be a computer.

Here are a few examples:

Cars: cars contain many embedded systems from fuel control, anti-lock braking, transmission control, dashboard display, ignition timing and many many more. I once read that the average car contains more than a dozen embedded systems.

Dumb cell phones: The cell phone needs a computer to interact with the over-the-air digital data network used to make phone calls. I exclude Smart cell phones because these are so powerful and flexible (with applications) that they are closer to hand held computers than to the dumb cell phones of old.

Vending machines: Like the car above, these are actually a number of embedded systems in one package. The devices that accept coins, bills, and credit cards for payment are little embedded modules within the whole, and the vending machine controller is an embedded system too. I can say that I have personally worked on each of these components over the years. A prototype of the controller is pictured above.

Computer components: Many storage sub-systems are in fact embedded systems that work to make mass storage devices work. Hard drives and memory “sticks” contain their own computers hidden away in them. They can even be hacked for good or ill.

This web site is devoted to the joys and frustrations of programming these embedded systems. Very often, programmers must deal with complex protocols, demanding real-time performance requirements, difficult debugging, and limited or non-existent user interfaces. Yet, it is precisely these challenges that make this type of programming so interesting. It was fun (?) yes, but maybe not so relevant any more.

Embedded systems used to use a lot of 4 bit microcontrollers. These are all gone now. The poor performance, lack of features, and high cost of programming those relics has long since over-shadowed any cost savings. So too, lower end, more primitive systems are being pushed into smaller and smaller niches. When those niches dry up, so will the sales of those parts.

In the pages of this blog, we have reviewed the chips, their defects, the math behind how things work, the crazy things that the vendors do, and the many other things that affect programming at the bare metal level. Yet embedded programming IS changing. New products like the Arduino, Raspberry PI and the Beagle are bringing a new level of power, integration and ease of use to the embedded world.

The world is changing, and so must this blog. I have taken the plunge and obtained a number of these new embeddable systems and plan to focus on this new direction. This will mean a new emphasis on Linux, higher level languages and protocols, and yes even some web programming. I have a great deal of learning and exploring to do and I hope I can share this with you, my readers.

As always, your comments and suggestions are most welcome:

Best regards;

Peter Camilleri (aka Squidly Jones)

Share this:

Like this:

Recently, I posted an article about my work with random number generators. That work was all done in the Ruby programming language. Now Ruby is a fun language to program in, but I got to thinking that it is not the first choice for embedded work. (Yes, there is mruby, but it is still not well known) So it became clear to me that C or C++ would be good choices to explore.

So I set about porting my Fibonacci pseudorandom number generator to C++. It was not entirely a pleasant experience. I used Visual Studio 2013 (free edition) to do my development. My motivation for picking that tool was simple convenience. I supposed I could have set up Eclipse with GCC, but the tool setup time would have been excessive for my simple goal of evaluating a small bit of code. Further there can be no doubt that many alternative development communities provide little to no support for the majority of users who own Windows based computers. No VS is not perfect either. Most project templates start users off with code littered with non-standard, non-portable language extensions. To the best of my ability, I avoided and removed these. If I missed any, please tell me, so I can make the needed corrections.

It has been a few years since I’ve programmed in C/C++ in a professional capacity. In the beginning it seemed that everything I did was wrong. I was writing incorrect code in so many ways that the compiler was perplexed as to what I was trying to say. Over the course of a few hours though, things got better and soon, the IDE was starting to feel comfortable and productive.

So how did the two languages compare? Well the C++ code had a lot more “pomp and circumstance” to it. To give an example, the spin function that updates the internal random state looks like this in Ruby:

In fact, most of the entities in the class had to be specified twice, once in the header file and once in the source file. On the plus side, this extra detail made it possible for the IDE and the compiler to scrutinize the code to an extent impossible in Ruby. On the other hand this is a lot of extra drudge typing and ignores the fact the C++ developer is responsible for dealing with memory management, which is simple in this case; not so simple in normal, larger programs.

So what about the bottom line? How did the code perform? Well, running from the command line, on the same hardware, with the same algorithm, the C++ version was about one hundred times faster. The executable was a mere 7K in size. While these figures are impressive, they are of a trivial example. In real applications, things are much more complex. For now, this is but one data point, and one data point it shall remain. The C++ and Ruby code in question may be found on GitHub.

The basic idea behind the sequence was that each number is the sum of the previous two. My idea was what if an array of counters were maintained in a ring, where each value was the sum of the previous two? The numbers would cascade and overflow and become very chaotic. Still I was never sure if such an algorithm would actually work. I implemented it and it did’nt. The sums sped off until they were all zero. I fixed the algorithm by shifting one of the terms to the right by one bit and now it seemed to work. Still, I was haunted by that line from the essential text: “The Art of Computer Programming” that says (after expounding the flaws in many fine algorithms thought to be suitable):

The moral of this story is that random numbers should not be generated with a method chosen at random.

Donald Knuth

I had no way of determining the quality of the numbers generated, so my code languished on the back burner. I realize now that what I was lacking was an understanding of statistics and statistical analysis. I went to university, but I am sad to say that I never took a stats course. I really wish I had.

Normally, I can figure things out from Wikipedia, but maybe my cognitive facilities are fading because it was mostly just greek to me. A few things stood out. The Chi² measure is often used in grading pseudo random number generators. I created a test bed and ran 10,000,000 iterations of a six way test (like a cubic dice) using both my creation and the one built into the Ruby language (ruby 1.9.3p484 (2013-11-22) [i386-mingw32]). Lower values of Chi² indicate closer conformance to the expected distribution of results. The values obtained were:

Generator

Chi Squared Value

Home brewed

6.040861333333967e-08

Built In

1.7266209333333707e-07

Now, I still don’t know how to interpret these results fully, but my home brew generator had lower scores which means the values were more evenly distributed. Which is good… I think. I was still very uncertain. The second test I tried was an Auto-correlation test. The nature of this test is too complex to explain here except to say that it is excellent in finding hidden patterns in seemingly random data. Here are the results:

Fibonacci Generator

Internal Generator

The correlation is high when the data is compared literally to itself. This is expected. Note that as soon as the comparison starts to shift, correlation collapses and becomes essentially random. This is also expected. So far my homebrew code is holding out.

The final test is a simple scatter graph. The random number generator is used to generate random coordinates that are plotted on a graph. Patterns in the data will show up as patterns in the graph that may be visible. Here is the result of this test.

Fibonacci Scatter

And this is where things stand so far. All the tests I have run give me the confidence that my little algorithm produces random numbers at least as well as commercial generators, while using only addition and divide by 2 and no higher math operators. The code for this project may be found at: https://github.com/PeterCamilleri/fibonacci_rng. The code is also available as a Ruby Gem at: https://rubygems.org/gems/fibonacci_rng. Take a look at the code if you like, use for any purpose, just don’t expect any guarantees! After all, 9,9,9,9,9,9,9,9… could be a random sequence!

As always, comments and suggestions are most welcome.

Best regards;

Peter Camilleri (aka Squidly Jones)

[Update] November 29, 2014

I recently watched the most fascinating video about the cracking of the Enigma cipher in World War 2. Here is a link to Turing’s Enigma Problem – Computerphile. The most fascinating thing for me was the analysis of the enemy’s efforts to make the code harder to crack. These changes resulted in inconsistencies that actually made it easier to crack! It re-affirms Knuth’s assertion that random things done at random are NOT assured to increase security!