The presentations released this week are about APL applications on the move. Some applications are moving from one APL implementation to another, for example from APL2 or APL+Win to Dyalog APL. Others are moving from one platform to another, for example from a mainframe or the Microsoft Windows desktop to Linux in docker containers in the cloud. Sometimes both moves are being considered – the need to switch platforms often triggers a review of which APL system to use on the new platform.

Migrating to Dyalog APL

OLE or ActiveX is an old technology which is being replaced by web services using tools like Jarvis. However, quite a few existing applications use it to make APL business logic available from tools like Microsoft Excel. Dyalog allows you to turn any namespace into an OLE Server with an API that is specific to your application – this requires the design of an object-oriented API. APL+Win comes with a simpler (evil tongues might say less secure) but in some ways easier-to-use framework in which a single OLE Server called WSEngine allows you to load any workspace and execute code within it. Jürgen Wiedemann from Dittrich und Partner Consulting (DPC) shows how the Dyalog framework can be used to implement something very similar to the APl+Win tool. Not only does this simplify some migrations, it also provides a simpler OLE Server framework for users of Dyalog who don’t need or want an application-specific API.

We are in the process of migrating the METSIM® application from APL+Win to Dyalog. As part of this project, we are developing general-purpose tools for moving APL source code from other APL systems to Git, performing automated translation and/or emulation of language features not directly supported by Dyalog. Karl Holt and I present the current state of these tools, including the current prototype of a function named ∆WI, which emulates ⎕WI from APL+Win or MicroAPL APLX, and will help move GUI applications to Dyalog with minimal application code changes. All these tools will be made available free as public repositories on GitHub.

Markos Mitsos of ERGO insurance has taken a completely different approach to his migration from APL+Win to Dyalog. Rather than use tools like those described in the previous two presentations, which aim to minimise the changes required to application code, Markos has carefully studied the Dyalog APL language and tools, and decided to refactor his old code to take full advantage of the new platform. This obviously takes much longer than using semi-automated migration tools. In his presentation on workspace transformations, Markos explains why he feels the extra work was worth it.

New GUI Frameworks

First, a bit of fun: RayLib is a simple and easy-to-use library for video game programming (although it can be used for more serious purposes). Brian Ellingsgaard is the creator of raylib-bqn, an interface from BQN, which is an array language with many similarities to Dyalog APL. He spent this summer with us as an intern, creating a similar interface from Dyalog – the result is raylib-apl. In his presentation, he gives examples of 2D and 3D game programming using RayLib…including the mandatory 3D duck rendering!

The original goal of our Everywhere WC project (EWC) was to allow existing applications using the Microsoft Windows GUI based on the ⎕WC system function to be moved to other platforms, including Linux in the cloud. EWC provides cover-functions that emulate the ⎕WC family of functions using a JavaScript (React) application to recreate equivalent GUIs. This allows applications to be migrated to Linux and macOS (or Microsoft Windows) desktops using the HTMLRenderer, or to any platform with a web browser to render the user interfaces – with minimal changes. However, the implementation also supports changing the look and feel using CSS styling, Flex layout for responsive UI, and several new controls based on JavaScript libraries like the ApexCharts graphics package. In this presentation, I also suggest that it has potential for completely new applications.

In the 1980s, Pete Donnelly and Geoff Streeter oversaw the design and development of ⎕SM, a system function for creating text-based (“80×25”) user interfaces. When Graphical User Interfaces came with Microsoft Windows, Pete worked with John Daintree to design ⎕WC, a system function for creating GUIs under Windows. In both cases, these features were quickly mastered by APL users, and subsequently used to build many of the most successful applications written in Dyalog. Now that applications increasingly need to be cross-platform and/or remotely controlled, Pete has been Noodling*, searching for intuitive ways for APL users to define cross-platform, HTML-based UI, based on popular widget libraries. Given his track record, it is worth paying attention to Pete’s Noodles!

* John Daintree refers to experiments as “Noodles”

——————————————

This week’s videos:

• U10: Deployment of the Dyalog Interpreter as an OLE Server for Interactive Use (Microsoft Windows Only) (Jürgen Wiedemann)
• D09: Migrating APL+Win Applications (Morten Kromberg and Karl Holt)
• U09: Migrating to Dyalog from APL+Win: Workspace Transformation (Markos Mitsos)
• U03: raylib-apl – A Simple Cross-Platform Library for Graphics, Sound, Interactivity, and more (Brian Ellinsgaard)
• D07: Everywhere WC (Morten Kromberg)
• U12: Noodle, A Cross-Platform, Object-Oriented Framework for Developing Single-User Desktop Dyalog GUI Applications (Pete Donnelly)

Materials for all presentations can be downloaded from the Dyalog ’24 webpage.

Follow