Developing A Game Engine with Perl: Part 5 - 32bit -> 64bit & Perl's Storable

If you haven't heard already... I DO NOT KNOW WHAT I AM DOING.

If you want to start reading from the beginning. Check out the first article in this series

Continuing on with the last article let's talk about changing system architecture and how that can affect Perl code, specifically Storable.

• Mouse Input Support
• Hardware Failure
• Server Upgrade
• UEFI vs OpenSuSE Installer
• 32bit -> 64bit & Perl's Storable

After the old server had HDD failures and finally managing to upgrade to the new server, I eagerly began getting all the services and software installed to test the engine on new hardware. I was quickly meet with an error I have never seen before.

Byte order is not compatible at /usr/lib/perl5/5.34.0/x86_64-linux-thread-multi/Storable.pm

After doing some quick reading, I came to understand that Perl uses architecture specific ways to save content to files when using Storable. Specifically if you use lock_store and store. These are part of Perl's core system and what I use throughout the engine for working with the file structure.

I had to carefully re-read the perldoc's to discover that you can avoid architecture incompatibility by simply using nstore and lock_nstore The method you use for retrieving the stored files doesn't matter, only when storing the data into files does it matter.

I tried to find ways of being able to convert the stored files from 32bit architecture to 64bit, but ultimately the only real option was to use the old server to re-store the files with lock_nstore.

Luckily the old PC was still working, and I was able to modify the code and re-store all the files. The change and usage was simple:

I had to change my use statement from:
use Storable qw(lock_store lock_retrieve);
to
use Storable qw(lock_nstore lock_retrieve)

And to re-store I changed my code from this:
lock_store($data_ref, $dir_location);
to
lock_nstore($data_ref, $dir_location);

Have you ever had to write code for architecture compatibility? Or fix code migrated from one architecture to another? What do you prefer for storing data to files in Perl?

If you have any suggestions or comments please share constructively. Also please visit our social media pages for lots of fun videos and pictures showing the game engine in action.

ANSI Game Engine on Instagram
ANSI Game Engine on Facebook

Prev << Part 4 - UEFI vs OpenSuSE Installer
Next >> Part 6 - A Colourful Telnet Server

Cheers!
Shawn

Comments

[grifferz]

There's a reason why sqlite is on pretty much every phone in the world - it's a great way to store local app data, solves a lot of durability and portability issues!

[Shawn Holland]

Thank you @grifferz for the information! I will read up on sqlite.