terebinth update

A little while back, I was working on writing an interpreted programming language using C++ as the medium for the interpreter implementation. The repository for that project can be found here, and it has since been converted to a public archive. I was in the middle of investigating the feasibility of modernizing the underlying C++ implementation by moving from C++17 to C++20 with modules, but that task proved Herculean. I abandoned the project for quite awhile until I made a concerted effort a few days ago to get involved again. I soon realized why I had abandoned the modernization effort in the first place, and I considered cessation of the project altogether.

I then had the idea to just archive the original implementation of the project as-is, but instead of discarding the project entirely, I have now decided to pursue reimplementing the code in Rust. This would ensure that the foundation of the terebinth language would be memory-safe and robust. I also decided to change the way I approached the terebinth language. Instead of creating an interpreter, terebinth will now be a compiled language with the full compiler stack written in Rust.

This effort will require a lot of time and dedication, but I am willing to invest the resources necessary to complete this project. The new terebinth repository can be found on GitHub, and a release is available on crates.io. It should be noted that the release is not at all a working product; I published a rough cut just so I could reserve the package name. Subsequent releases will follow as I make progress on the compiler. I will post updates here as well, as I have done with previous projects such as open-dis-rust (which should be moving out of alpha and into beta releases soon).

I plan to clean up a lot of the loose ends that I have currently on GitHub, whether that mean that I delete/archive repositories or get those in-development projects to a state where they are finalized and released. Once that has been accomplished, I will have more of my attention to devote to finishing open-dis-rust and terebinth. As things progress, updates will be posted here if such changes warrant.

This project was something that I wanted to do simply out of curiosity and out of desire for a challenge. I am still very much learning the fundamentals of writing compilers and developing a good programming language, and I don’t anticipate that terebinth will ever be useful to the industry; that doesn’t matter to me, though. I see this as an opportunity for growth and development as a professional in the field of computer science, so the success of the project is not as important as the completion of it. This is a project that I hope will serve as a stepping stone, as something that serves as a building block for bigger and better software in the future.

Release: opendis6 v0.1.0

In tandem with creating an Open DIS package for Rust, I have also been working on modernizing an existing C++ library implementation of the standard. The original library can be found here. The original was autogenerated using an XML parser library that read in the IEEE’s documentation and output C++ code that implemented classes for all the PDUs defined within. This code is several years old and does not adhere to modern C++ style and standards. It is also bug-prone, and it has not received much TLC since its inception. I originally opened a PR in an attempt to clean it up, but I decided that the changes needed to actually complete it and modernize it warranted its own project. With that, opendis6 and opendis7 were born. The latter library has not been implemented yet, but it will be released in the future. For now, opendis6 is available on GitHub via source or on conan.io as a Conan package.

The “6” in the library name is in reference to the sixth revision of the standard: IEEE 1278.1a-1998. This is still widely used across the industry for distributed simulations, so it is vital that it is modernized and kept tidy. As for the “7” in the opendis7 library, that refers to the seventh and latest revision: IEEE 1278.1-2012. Although it is the latest version of the standard, developers can be stubborn when it comes to managing versions of dependencies. Moving to the latest technologies or standards can be challenging, and the effort to migrate to the latest and greatest can sometimes outweigh the benefits. I will eventually get opendis7 released, but it is not much of a priority with the previous thought in mind.

I will continue to maintain opendis6 for as long as I can, but the current version should suffice for most applications. There are a few more improvements I want to add, so subsequent releases should be expected. In the meantime, I will also continue my efforts to get the Rust crate in a releasable state. As with all things, I will post updates to this website.

If users notice any bugs or issues, please report them on the GitHub by opening an Issue or Bug Report. If anyone has changes they want to make, feel free to open a PR and tag me as a reviewer.

Pre-release: open-dis-rust v0.1.0-alpha.8

This is the second pre-release of the day! With this publication, the Logistics family of PDUs has been completed. Now, only 17 PDUs remain. In reviewing the README within the source tree, I realized that I had two PDU types listed that actually do not exist within the standard. I was using the Open DIS C++ library as a reference originally, and it, too, referenced PDUs that did not exist in the IEEE 1278.1 standard. So, having removed those errors, there are now only 17 PDUs left to implement. The remaining PDUs are primarily members of the Entity Management and Synthetic Environment protocol families.

Pre-release: open-dis-rust v0.1.0-alpha.7

With this pre-release version, the Minefield protocol family has been implemented. There are now 24 outstanding PDUs that need to be implemented according to the 2012 version of the IEEE 1278.1 standard. All the latest documentation regarding this pre-release is available on the crates.io page for the package.

Pre-release: open-dis-rust v0.1.0-alpha.5

The Radio Communications protocol family has been implemented in this latest pre-release version. Only 28 PDUs are unimplemented at this point, with a majority of those being within the Minefield protocol family. The next pre-release will address the Minefield PDUs and some other minor cleanup issues. As it stands now, I anticipate there being two or three more pre-release versions in the alpha stage before this moves into beta. From there, it is all bug testing and cleanup before v0.1.0 is cut and released.

As always, I will post here with major updates concerning this project.

Pre-release: open-dis-rust v0.1.0-alpha.4

Since v0.1.0-alpha.1, three versions have been released on crates.io. The Simulation Management Family and Simulation Management with Reliability Family PDUs have been fully implemented, and multiple security and quality tests have been performed and accounted for. This package is still very much a work in progress, but the December timeframe initially discussed is still valid for the v0.1.0 release. Just under 1/2 of the PDUs defined in the IEEE 1278.1 standard have been fully implemented; the SIMAN PDUs are arguably the most pertinent for generalized simulation management, and these have all been accounted for. With this still being in the alpha stages, the package is considered unstable and not fit for commercial or professional use at this time.

Before cutting the v0.1.0 official release, this package will go into beta for further testing and stability fixes. Once a release candidate is identified, this will go live on crates.io as a full release ready for general usage. I plan to maintain this package for as long as possible, and I will continue to provide bugfixes and security updates as needed.

Below is a copy of the markdown README provided with the source code that shows the current support status for all the PDUs defined in the DIS standard. The chart below will NOT be updated with future releases; all future changes to this chart can be viewed here on GitHub.

Supported PDUs

PDU Type Supported?
Acknowledge
AcknowledgeReliable
ActionRequest
ActionRequestReliable
ActionResponse
ActionResponseReliable
AggregateState
ArealObjectState
CollisionElastic
Collision
Comment
CommentReliable
CreateEntity
CreateEntityReliable
Data
DataQuery
DataQueryReliable
DataReliable
Designator
Detonation
ElectromagneticEmissions
EntityState
EntityStateUpdate
EnvironmentalProcess
EventReport
EventReportReliable
FastEntityState
Fire
GriddedData
IntercomControl
IntercomSignal
IsGroupOf
IsPartOf
LinearObjectState
Logistics
MinefieldData
MinefieldQuery
MinefieldResponseNack
MinefieldState
PointObjectState
Receiver
RecordQueryReliable
RemoveEntity
RemoveEntityReliable
RepairComplete
RepairResponse
ResupplyCancel
ResupplyOffer
ResupplyReceived
Sees
ServiceRequest
SetData
SetDataReliable
SetRecordReliable
Signal
StartResume
StartResumeReliable
StopFreeze
StopFreezeReliable
TransferControlRequest
Transmitter
UnderwaterAcoustic

Release: color-roulette.nvim v0.2.1

I actually released this version of the plugin wayyyy back in October of 2022, but I realized I never made a post about it. The release before (which was v0.2.0) overhauled my original plugin – which, again, was a joke – and actually implemented a somewhat decent roulette-style color randomizer. The patch release, which is the release version pertaining to this post, just updated some minor components of the code base without changing anything in particular with the functionality of the plugin. The latest version of the plugin can be found here. As always, documentation is available in the README on the GitHub page. I’ll start posting the changelog here for my software releases as they come through.

Release: autoref.nvim v0.1.0-alpha.1

I have started work on a couple new plugins for neovim, and one of the latest in that collection is autoref.nvim. This plugin will generate a formatted table/listing of all assigned neovim keybinds, and I plan to add some customization to it to allow users to add comments to each keybind for better, personalized documentation. Right now, this plugin is in the early stages of development, and it is not considered stable. The pre-release is available here, and installation instructions are provided in the README. As with all these plugins, I appreciate feedback and would like to see issues or PRs for suggestions. I’ll post more updates here as I continue my progress.

Release: autocommit.nvim v0.1.1

As I had posted awhile back, I did intend for autocommit.nvim to be a serious plugin at some point. It started off as a bit of a joke, but I have given the code base a facelift and real purpose. A stable release is available here. Installation instructions are provided in the README. The code has been drastically reduced and simplified, and I plan to add a couple more features in the future to make it more robust. Feel free to create issues or PRs to suggest new features or changes.

Neovim Plugins

It’s been another hot minute since I have posted, but in that time, I have begun dabbling in the realm of Lua and Neovim plugins. Neovim is an upgraded version of the classic Linux Vim text editor, which is itself an upgrade of Vi. Neovim has tons of support for plugins and color schemes alike, and using Lua, I have created a few of my own. Links to those repositories will be published in the “Projects” tab of the website. Let me briefly describe what each of these plugins are and what they do.

Autocommit

Autocommit is a plugin that started out as a joke with a simple concept: every time a user saves a file that is in a local git repository, those changes will be automatically committed and pushed. This is certainly not ever going to be useful at its current state, nor was it intended to have a real application; however, in future versions, this plugin will be cleaned up to perhaps have a better functionality. Right now, it has a few quirks and bugs to be ironed out, but for a spur-of-the-moment joke plugin, it works surprisingly well.

Color-Roulette

This is another joke plugin that I may refactor to be actually useful in the future. The idea for this was also pretty straightforward: the user is allowed to configure up to five favorite color schemes, and a color scheme is chosen at random on startup. The catch is that a hardcoded light-mode plugin is also in the mix to be chosen, meaning that there is a 1/6 chance that light-mode may be enabled at any given startup. This will eventually be phased out to perhaps be an Easter egg configuration parameter in favor of a more useful color scheme randomizer.

I plan to work on other plugins in the future, and I’ve learned a lot of fun things about Neovim and writing plugins with Lua. I’ll continue to post updates here as they occur.