twinBASIC Weekly Update

twinBASIC Update: May 30, 2021

Highlights include improved compiler stability, making the Optional keyword optional, and setting command-line arguments for debugging.

Mike Wolfe

• 5 min read
twinBASIC Update: May 30, 2021

On April 23, 2021, I helped Wayne Phillips introduce the world to twinBASIC at the Access DevCon Vienna conference.  I boldly predicted that twinBASIC (along with the Monaco editor) would replace VBA and its outdated development environment by 2025.  With that goal in mind, this weekly update is my attempt to keep the project fresh in the minds of the VBA development community.

Every Sunday, I will be providing updates on the status of the project, linking to new articles discussing twinBASIC, and generally trying to increase engagement with the project.  If you come across items that should be included here, tweet me @NoLongerSet or email me at mike at nolongerset dot com.

Last week was a slow week with no published twinBASIC updates.  This week made up for that.  There were eight (!) releases this week with a host of improvements and bug fixes.

Highlights

Improved stability and memory management

After 17 days between releases, version 0.10.220 included a:

"major overhaul of internal compiler memory management. work still ongoing, but drastic improvements for larger projects in this update"

"Internal compiler memory management" is to a programming language what the foundation is to a house.  It's something you never see and never think about...unless it's not done right.

Not the sexiest improvement, but an important one nonetheless.

Optional keyword is ... optional

On the other end of the spectrum is this change in syntax that makes the Optional keyword optional (how meta is that!), so long as you provide an explicit default value.

So, now in addition to this...

Sub Foo(Optional Bar As Integer = 42)
Traditional approach.

...you can also do this...

Sub Foo(Bar As Integer = 42)
The alternative twinBASIC approach.

Of course, in keeping with its backward compatibility promise, the traditional approach of including the Optional keyword will always be supported.

Debugger command line arguments

You can now set command-line arguments within Build Configurations:

This option is available in the Build Configurations screen.

Around the Web

There is a Discussions page at the twinBASIC GitHub project site where you can engage with Wayne Phillips on evolving aspects of twinBASIC.  I'll highlight a few of the conversations taking place there.

Project files should be human readable

Andrew Mansell began a discussion about the decision to use a binary container file (.twinproj) as opposed to plain text files.  His point–one that is near and dear to my heart–is that binary files don't play nicely with modern version control systems.

Wayne countered that the .twinproj files are not typical binary files, but rather container files.  They are more analogous to .zip files.  Wayne cites several reasons for making this choice.  Most importantly, though, he recognizes the need to support version control, both inside and outside of VS Code (emphasis mine):

"We will be providing a simple extraction tool for twinproj files, so that you can do SCC outside of VS code if you wish, but ultimately the main aim is to offer SCC inside VS code (which doesn't actually see the twinproj file itself, only the contents via its virtual file system)."

Lest you worry about whether you will be able to reconstitute a .twinproj file from the exported source code, Wayne assures us that such a feature is also forthcoming:

"tB will be able to reconstruct the twinproj file fully from the repository.   At the moment, things like breakpoints are stored as meta data rather than actual files in the virtual filesystem, but this will be changing soon so that literally everything will be able to be cloned to/from a repository."

If you're interested in version control, I recommend reading the entire exchange.

GUI Coming Soon!

Okay, "soon" is probably the wrong word.  Perhaps "GUI Coming Next" would be more accurate.

In any case, Wayne announced that he has settled on an approach for GUI support:

"In other news, I thought it worth mentioning here that I've now decided on the approach for GUI support.  twinBASIC will eventually offer two types of GUI forms.  One for Windows-only, which is fully backwards compatible with VB6, and a second type of form that supports cross-platform but is not 100% backwards compatible.  I'll be making every effort to make the cross-platform forms 'feel' like VB6 forms as much as possible, and the form designer will be shared between them both."

There are some very Windows-specific features built into the VB6 GUI platform, including Windows handles and ActiveX controls.  Those things will be supported for backwards compatibility.  For cross-platform projects, you will need to convert existing forms to their cross-platform equivalent.  It will be interesting to see how much–if at all–that process can be automated.

Changelog

Here are the updates from the past week.  You can also find this information by installing the twinBASIC VS Code extension and clicking on the Changelog tab of the extension page:

[v0.10.655, 29th May 2021]

  • added: support for RSet statement

[v0.10.621, 29th May 2021]

[v0.10.580, 28th May 2021]

[v0.10.575, 28th May 2021]

[v0.10.540, 28th May 2021]

[v0.10.509, 28th May 2021]

[v0.10.313, 27th May 2021]

[v0.10.220, 27th May 2021]

  • improved: removed the single source file limitation
  • improved: 'add component' UX from the twinBASIC VS code panel
  • improved: major overhaul of internal compiler memory management. work still ongoing, but drastic improvements for larger projects in this update
  • fixed: caching issues
  • lots of (minor) internal performance and stability improvements

Never miss an article.

Sign up to receive a Sunday morning email with links and recaps of the seven articles published that week.
(I'll never sell your email. Unsubscribe any time.)


All original code samples by Mike Wolfe are licensed under CC BY 4.0