twinBASIC Weekly Update

twinBASIC Update: August 6, 2023

Highlights include a big boost to IntelliSense performance, a "Paste Code as Comment" shortcut key, and discussion around inline assembly support.

Mike Wolfe

Aug 6, 2023 • 4 min read

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.

Here are some links to get involved with the project:

Highlights

IntelliSense Performance Boost

BETA 368 included a couple of performance improvements to IntelliSense:

Initial build times greatly reduced
IntelliSense data cached, providing a further boost (especially to large projects)

The early feedback is very positive:

[fafalone]: huge improvement for intellisense in new version, just trying it out now, night and day. virtually no lag at all, compared to 6-8s for every time previously

[sokinkeso]: Copy-paste (duplicating code, for small changes or testing), also improved amazingly!!!

Paste Code as Comment

In the twinBASIC IDE, the shortcut [Ctrl] + [Alt] + [V] will now paste the contents of the clipboard as a comment (i.e., it will prefix each line with an apostrophe).

Discord Chat Summary

^{* Auto-generated via Claude-2-100k on poe.com}

Here are some key highlights from the Discord conversation about twinBASIC:

twinBASIC detects when two user-defined types (UDTs) are the same and allows substituting one for the other. This allows for aliasing support.
The intellisense in the latest twinBASIC version is much faster, with virtually no lag compared to 6-8 seconds previously. This makes working with larger projects like those using tbShellLib much more usable.
Inline assembly support is desired by some as a way to optimize certain operations, though it would only be needed in rare cases. There was discussion around the pros and cons.
The ability to easily disable error handlers for debugging, like VB6's "break on all errors" option, would be useful to add.
Huge improvements were made to the speed of copy-pasting and code duplication.
There is interest in adding support for vbWatchdog, a library for more robust error handling without reliance on line numbers.
Parameterized constructors are only valid within twinBASIC projects currently. Factories or property lets are ways to emulate them for general COM use.
Calling conventions like cdecl need to be properly declared when calling external DLLs to avoid crashes.
There are some remaining garbage collection pauses that delay recompilation, but improvements have been made.

[Follow-up prompt]: What are the pros and cons of adding inline assembly support to twinBASIC?

Here are some potential pros and cons of adding inline assembly support to twinBASIC:

Pros:

Allows optimizing performance-critical code segments by directly controlling the processor instructions. This can sometimes outperform compiler optimizations.
Provides the ability to write code that interacts with the hardware at a very low level, for things like memory fences, atomic operations, etc. This can help prevent race conditions and crashes in multithreaded code.
Allows access to processor instructions not accessible through the high-level language. Can enable certain advanced techniques.
Experienced assembly programmers could write optimized functions/libraries in asm for others to easily utilize.

Cons:

Inline asm code is platform-specific and not portable. It would need rewriting for different processor architectures.
It can disrupt compiler optimizations and analysis like dead code elimination. The compiler doesn't know what the asm code is doing.
Can potentially cause crashes/instability if used incorrectly. Writing robust inline asm requires significant expertise.
Can harm readability and maintainability compared to high-level language code.
The benefits beyond compiler optimizations are limited to very specific niche cases. The performance gains may not be worth added complexity.
Alternative solutions like using external asm libraries may be preferable for sharing optimized asm code.

So in summary, inline asm enables control over hardware and optimizations in select cases but requires expertise and can reduce code quality if overused. It's a niche feature that may not be needed by most twinBASIC programmers.

Around the Web

Nothing of note this week.

Changelog

Here are the updates from the past week. You can also find this information by visiting the GitHub twinBASIC Releases page.

WARNING: The following issue is present in BETA builds 202 - 3xx (the latest build as of publication):

there are known memory leaks in these versions, so memory usage will be higher than normal

BETA 366

fixed: localized strings using IDs above 32767 would cause a crash during building [ fafalone, discord ]
fixed: (regression) 'Active Control' project contained an error [ fafalone, discord ]
fixed: correction to handling when dot operator is split via a line continuation [ uiwoow, discord ]

BETA 367

fixed: (regression) errors in API declarations not showing at the definition in the IDE [ https://github.com//issues/1646 and https://github.com//issues/1633 ]
fixed: IDE clipboard paste auto-indent incorrect handling of pasting of Else block [ fafalone, discord ]
fixed: IDE clipboard paste auto-indent single-line-if handling [ https://github.com//issues/1642 ]
fixed: assigning empty byte array to String causes runtime error [ https://github.com//issues/1623 ]
improved: added 'Paste As Comment' feature (Ctrl-Alt-V, similar to old VS Code edition) [ krool, discord ]

BETA 368

improved: faster intellisense build times (approx halved)
improved: intellisense data is now cached, giving much better response times for packages such as tbShellLib