DYNA Spring 2025: A Review

Earlier this month we hosted a DYNA (Dyalog North America) event. We returned to the same venue as DYNA24, and again had a capacity crowd.

The day started with an update from our CTO, Morten Kromberg, regarding the latest developments at Dyalog Ltd – both within the company and with Dyalog and its associated offerings. One notable change is a transition in how we will provide the documentation. From Dyalog v20.0, we are moving towards using open-source markdown-based documentation on GitHub. The benefits of this approach are improved searching functionality and the ability for more people, internal and external, to contribute. If you see an issue with the documentation, you can raise a GitHub issue or even submit a correction as a pull request.

Several new tools are in progress, including:

  • an interface to Apache Kafka, which is a popular open-source distributed event streaming platform used by thousands of companies.
  • a tool to perform static analysis of APL code that will detect vulnerabilities and other bad practices. This will help our customers adhere to “best practices” for software vulnerability analysis.
  • leveraging AI both to help our customers develop APL code and to help them use AI in their own applications.

Morten then spoke about the current and forthcoming versions of Dyalog, sharing the highlights of v19.0, reviewing v19.4.1(!), and previewing v20.0, which will be available later this year. Among its many features are two highly anticipated ones:

  • Array notation – this will have a significant impact on how arrays can be specified in code. Creating namespaces is now particularly easy, as rather than creating a namespace and subsequently assigning values in the namespace, they can be completely specified in notation.
  • Inline tracing – this will allow the developer to trace each element of an APL expression, displaying information about left and right arguments, operands, and so on. This should help make understanding long or dense lines of APL code much easier.

Morten’s second presentation focused on efforts to provide sets of migration tools for two different purposes – to migrate applications that are currently using Dyalog’s ⎕WC to non-Windows platforms, and to migrate applications written in other APL implementations to Dyalog APL.

EWC (Everywhere Window Create) is intended to be as syntactically identical to ⎕WC as possible to simplify the process of enabling existing ⎕WC applications to run on platforms other than Microsoft Windows with virtually no changes. EWC uses HTML, JavaScript, and CSS in the HTMLRenderer or a browser to render the GUI. This opens up the possibility for users to integrate other JavaScript libraries, inject custom CSS, or develop custom controls to add additional GUI elements beyond those that ⎕WC can provide alone. Neil Kirsopp is our resident JavaScript expert, and is leading the client side of EWC. Morten showed screenshots of an existing ⎕WC application and its EWC equivalent, as well as a new EWC application that he developed to help track the administrative work necessary for maintenance and scheduling of the sailing ship he co-owns.

Morten Kromberg presenting at the DYNA Spring 2025 APL event in New York City. He is pointing at a screen displaying a sailing ship interface, which includes ropes, rigging, and a schooner in the background.

Photo by Devon McCormick

Morten next discussed source code migration from APL+Win to Dyalog APL. The challenge of migrating a “living” application where changes are being made to the APL+Win code while it is also being converted to Dyalog APL has resulted in a methodology using code in parallel text files, using Git for source code management. A framework to translate the syntactic incongruities between the two APLs has been developed. Perhaps the most daunting difference lies in the GUI architectures. APL+Win uses ⎕WI where Dyalog APL uses ⎕WC. A new tool that we have developed to ameliorate this is ∆WI, which is a ⎕WI emulator that uses ⎕WC under the covers. Although work is not yet complete, the pilot customer is very pleased with the migration effort and the performance of ∆WI.

Morten also noted that many ∆WI-based applications can run using EWC and, therefore, should be able to run in the cloud. Davin Church (Creative Software Design), with his extensive APL+Win experience as well as his Dyalog experience, has been enlisted to help develop ∆WI. At this point, Davin joined Morten and mentioned that when he compared Dyalog’s APL-based equivalents to APL+Win’s C-based “fastfns”, the Dyalog code typically ran slightly faster.

Mark Wolfson (BIG) spoke about how Dyalog is used within his company. BIG has revolutionised the Jewelry industry, and their product is known for accommodating and handling many different input files and formats from jewellery shops across the USA. Mark is quick to advocate for, and experiment with, some of the newest Dyalog features. Now with Jarvis and EWC, he has been able to very quickly deploy new front-end features to his customers, sometimes sometimes even while they are describing their problem to him over the phone! This is in stark contrast to trying to create a ticket to get the same features built and created by the C# development team.

Mark Wolfson speaking at the DYNA Spring 2025 APL event in New York City. He gestures with a presentation remote while discussing a topic, with a whiteboard containing Wi-Fi details in the background.

Brian Becker then presented “The Many Faces of Jarvis”. Jarvis is Dyalog’s web service framework that can be used to deliver JSON or REST-based web services – it provides a mechanism for clients to access your APL code over the net without them having to know anything about APL. Since its inception, Jarvis has become a key component of many Dyalog projects, both internally and amongst our customers. Brian described how features have been added to Jarvis in direct response to customer needs.

Josh Davis showcased some of the tools and functionality that are used in day-to-day development. He decided to live dangerously, and demonstrated this by working out a problem in real time using some of the public datasets made available by New York City. He did an analysis and produced a report of tree data (the plant, not the datatype!) across the five boroughs. It involved the use of some newer primitives such as the key and at operators, other system functions for reading/writing files, the HTMLRenderer and a JavaScript plotting library, COM for Microsoft Windows automation, .NET for cryptography routines, SQAPL for database access, HttpCommand for web requests, and ⎕R for regular expressions support. All these tools come with a Dyalog installation.

Josh David presenting at the DYNA Spring 2025 APL event in New York City. He is seated in front of a large screen displaying a slide titled "Leveraging Community Packages," which lists various technologies and tools used with Dyalog APL.

Photo by Devon McCormick

Max Sun (BCA Research) presented a demonstration of some of the tools he used to build the talk he gave at LambdaConf last year; he runs APL examples in a Jupyter Notebook, using SharpPlot for plots.

Brian and Mark presented thoughts and developments on Dyalog and AI. Brian posed two questions:

  • How can Dyalog use AI to help our customers?
    • Making documentation easier to search and navigate
    • Explaining what a piece of APL code is doing
    • Generating APL code
  • What can Dyalog do to help our customers use AI?
    • What tools can we provide to help our customers to integrate AI into their applications

Integrating APL and AI faces several challenges. Firstly, there’s very little APL with which to train Large Language Models (LLMs), especially compared to languages like Python and JavaScript. This can lead to frequent “hallucinations”, where the LLM just makes something up. Secondly, APL is not a focus for AI purveyors. Although there is documentation and packages for Python and other language to interface to LLMs, it’s up to us to develop them for APL.

Brian demonstrated a Google NotebookLM, into which much of the Dyalog documentation had been uploaded. This provided “context” for the LLM, which made the search results more accurate and applicable. Next came a demonstration of Cursor, which is essentially Anthropic’s Claude LLM integrated within Visual Studio Code. Brian provided a dfn and asked what the code did. The response was impressively accurate. He then loaded the HttpCommand git repository and asked for a summary – again the results were impressive. Brian then showed how he asked an LLM to write a simple piece of APL code. The LLM got it wrong, which Brian pointed out. This went through several iterations, with the LLM profusely apologising for its mistakes as it went on to generate another, different, mistake! It should be noted that different LLMs will perform better or worse depending on what body of material they have been trained on, and new, better, LLMs are being rolled out all the time.

Brian has used HttpCommand to develop interfaces to OpenAI‘s and Anthropic’s APIs. Many LLMs are OpenAI compatible, which means their API is very similar to OpenAI’s. Developing and documenting interfaces to LLMs will continue to be a focus. Mark discussed how AI could be useful at BIG, citing real-world use cases to balance inventory, improve look-ups, and provide alternative items based on their attributes and photographic similarity. Mark also raised the question of using commercial cloud-based AI for proprietary data. How private and secure is your intellectual property?

Brian’s presentation on “The APL Ecosystem” highlighted the online resources that exist to help people learn APL and participate in, and contribute to, the APL community. The single most useful resource seems to be the APL Wiki, but there is also TryAPL, APLCart, APL videos on YouTube, APL-related GitHub repositories, Hacker News, the APL Orchard on Stack Exchange, the APL Farm on Discord, the APL Challenge, the APL Forge, and various APL-related presentations at LambdaConf, Functional Conf, and PLDI.

To close the event, Diane Hymas asked everyone to “remember how you felt the day you discovered APL”. This was her lead-in to introducing The APL Trust – a non-profit entity aiming to promote awareness and use of the APL programming language by funding APL projects, especially in the areas of STEM (Science, Technology, Engineering, and Mathematics). Although the initial plan was to have one global fund, for tax purposes it was more expedient to start with a US fund, with other related funds in the UK and EU to follow. Hopefully the APL Trust will become an incubator of some great new APL ideas and software!

After the day’s scheduled agenda, most of the attendees walked around the corner to the Yard House for dinner and drinks. All in all, the day was fun, informative, and a great opportunity to interact with other APL enthusiasts.

————————————–

All the presentation materials from DYNA Spring 2025 can be downloaded.

DYNA Fall 2025 will take place on 29-30 September – register for updates as information becomes available.

Dyalog ’24 Videos: Week 6 – Remembering the “Old”, Welcoming the “New”

The main theme this week is remembering how we got here – and welcoming a new generation of APL users. There are three talks and a panel discussion looking back on careers spent working on or with APL, and a final panel discussion with members of the new generation, which will hopefully wipe away some of the nostalgia.

John Daintree’s presentation Array Notation: A Journey of Discovery is the exception from the historical theme – the release was delayed until this week due to technical difficulties. However, John does point out that it is nearly a full decade since Phil Last’s initial APL Array Notation presentation at Dyalog ’15 in Sicily, and that Adám Brudzewsky has subsequently given several overviews of the evolution and experimental use of the notation (Literal Notation for Arrays and Namespaces at Dyalog ’17, Array Notation Mk III at Dyalog ’18, and Array Notation RC1 at Dyalog ’20). As Chief Architect at Dyalog Ltd, John has been working on the implementation of array notation within the Dyalog interpreter and IDE, and offers a sneak peek at array notation features that will be in version 20.0 – and some that are probably too adventurous to make it this time.

Veli-Matti Jantunen inherited reasponsibility for PxEdit when the original author decided to join FinnAir as a pilot. (Kimmo Linna is now an Airbus 350 Captain but still finds time to contribute tools to the Dyalog community – for example, RSConnect). In PxEdit to GitHub – Refurbishing a Seasoned APL Application to Open Source, Veli-Matti explains that PxEdit was originally a temporary hack for handling larger-than-usual tables at Statistics Finland, but it grew in popularity as Veli-Matti added functionality that users needed (like Unicode support). To cater to users in developing countries, Veli-Matti avoided using system features that would require the newest versions of operating systems, doing a lot of work in “raw APL” instead. 25 years later, PxEdit is used by 115 organisations in 45 different countries. Veli-Matti’s next task is to make it open source on GitHub, in the hope that a new person will pick it up so that he can retire!

The next retrospective presentation is Charles Brenner’s Some APL Pioneers that I Knew. If you are interested in the history of programming languages and the personalities behind languages like APL, this highly entertaining talk is a treat. On his way, Charles met, or worked with, Larry Breed, Kenneth Iverson, Eugene McDonnell, Adin Falkoff, Garth Foster, Curtis Jones, and Paul Berry – to name a few. Charles’ sense of humour is extra dry, so listen carefully to pick up several jokes that the audience did not get quickly enough to laugh during the presentation…

Geoff Streeter worked on Dyalog APL from the day it was conceived in 1981 until he retired 18 months ago. Key Technical Decisions During the Development of Dyalog APL is a walk through the history of the implementation and critical decisions made, starting with: Should we use C or Assembly Language? Target UNIX? Build a 1st generation (flat) or 2nd generation (nested) interpreter? Should it include productivity tools like ⎕FMT, and if so from which pre-existing APL interpreters? In his own words, expect some nostalgia, some repentance, some triumphalism, and some serendipity. Thankfully, many of those early decisions turned out to be excellent. None of us would have been in Glasgow in September 2024, more than four decades after the release of Dyalog version 1.0, if it had not been for Geoff!

Finally, Stephen Taylor wraps up the historical theme as the host of two panel discussions. In Let’s Put the Future Behind Us, we hear from the team who nursed the company and the product from a very shaky birth, where the company was reconstructed more than once – Pete Donnelly explains how he mortgaged his own house because he believed in the future of the product! Geoff Streeter worked without pay at times, but explains that he was not concerned as he abdicated worrying to management. Andy Shiers remembers how the sales of IBM hardware to British Airways helped pay for continued work on APL. Just past the halfway point in Dyalog Ltd’s current history (this is hard for me to fathom), Pete handed the baton to Gitte Christensen, who tells the story of how she fell in love with APL and “came home” in 2005 to take over the helm of a language vendor after starting her career at one of the original APL vendors, I. P. Sharp Associates (IPSA).

However, we cannot end a Dyalog user meeting looking back! In The New Breed Plugs In, Stephen asks Martina Crippa, Josh David, Sandra Persson, and Gilgamesh Athoraya how they found APL (or how APL found them, as some of them put it). What attracted them to APL? Beauty, having fun, and creativity seem to be important components of many explanations, but I should not say more – listen to the stories!

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

This week’s videos:

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

Dyalog ’24 Videos: Week 5 – Best Practices

Most of the recordings that we are releasing in week 5 concern “best practices” for the use of APL in large or complex systems. Many of these are mentioned in the invited keynote Dyalog APL in the Biggest Data Centres at the Heart of the Investment Management Industry by Oliver Lanz from the product development team at SimCorp, one of the biggest users of Dyalog.

In his talk, Oliver gives an overview of the architecture of Simcorp Dimension, which is the backbone of more than 50% of the top investment management firms worldwide; it manages over €35 trillion combined. Oliver explains the position that Dyalog has within their architecture, and how shared code files, the .NET bridge, multi-threading, and Simcorp’s homemade type checking system, all contribute to making the system secure and efficient. He introduces many of the topics discussed in the other talks released this week, and explains why it is important to Simcorp that Dyalog Ltd and the APL community develop and use such tools.

One of the points raised by Oliver Lanz in his talk is that developers are increasingly required to use automated tools to measure code quality, and document this to auditors. As applications are exposed to the outside world over the internet, an important goal of automated analysis is to detect and prevent vulnerabilities that would allow attackers to access or modify data without permission. In his talk Static Analysis of APL in APL, Brandon Wilson describes the work that he is doing with Aaron Hsu to teach the co-dfns parser about traditional functions so that it can parse existing APL application code and enable static analysis of APL code. Aaron follows up his compiler and parser status in Co-dfns Roadmap and Updates.

As APL applications become part of elaborate architectures where APL code provides and/or makes use of other services, another requirement that is emerging is the provision of telemetry to support the monitoring. This can be used to track performance over time and – when things go wrong – troubleshoot system failures that involve calls between multiple components, potentially implemented using different technologies. In their presentation on Telemetry and Protobuf, Gilgamesh Athoraya presents how OpenTelemetry can be used from Dyalog and demonstrates a sample application that emits telemetry data. Telemetry data can, optionally, be emitted using Protobuf (Protocol Buffers), a mechanism for serialising structured data. Sandra Persson joined him to present an APL implementation of Protobuf and a plugin that generates APL code from schema files.

Kai Jaeger is the most prolific tool builder in the Dyalog community. He is the author of many useful tools, both for use at runtime and during development. He has contributed the vast majority of the packages available on the Tatin package manager (which is also his work). In Developing in Dyalog with Modern Tools, Kai takes us through “a day in the life of an APL developer”, demonstrating the most important tools that he uses on a daily basis, to make development both easier and safer. Amongst other things, Kai demonstrates Git, GitHub, Cider, Tatin, Snippets, CommTools, FiRe, APLGit2, Testing (with code cverage), and CodeBrowser for code review.

I must admit that Brandon Wilson’s Data Parallel Proof Verification was not something I thought that I would fully appreciate, as my understanding of proofs and how to use them is extremely limited. However, I was still intrigued by the insight (obvious once Brandon has pointed it out) that proofs are tree structures, with a top-level proof being constructed from several smaller proofs. Brandon has been experimenting with using co-dfns/Hsu-style tree wrangling to validate proofs in parallel, and the results are very promising. As mathematicians move in the direction of software systems to make proofs more reliable, it matters a lot whether your new proof can be verified in a split second or it takes hours or even days. Although there are few current APLers who need a proof verification system, this could help make APL more visible to communities who are currently unaware of it.

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

This week’s videos:

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

Dyalog ’24 Videos: Week 4 – Migrating APL Code, and New GUI Frameworks

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:

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

Dyalog ’24 Videos: Week 3 – The APL Forge, Education, and Data Science

The recordings released this week focus on activities related to attracting new users to APL.

For many years, the APL Problem Solving Competition was a cornerstone of our efforts to promote APL to a new generation of potential users. This year, we introduced the APL Forge, where prizes are awarded for original work done in APL, rather than solutions to “classical” computer science problems. Our Managing Director (CEO) Stine Kromberg introduced the new format and presented the Grand Prize to this year’s winner, Holder Hoover. Holden, who is an aviation geek and still in High School, then explained how he built his own system for receiving and processing the ADS-B data that is transmitted by nearly all aircraft so that he can track aircraft within range of receivers operated by himself and a friend in the Azores. In three days (apparently between two exams), he managed to decode data using APL that he had spent three months failing to handle in JavaScript.

We were very pleased to learn that Sergey Ichtchenko and his two collaborators, Dani Adham and Hex, have been working on a MOOC (Massive Open Online Course) for the University of Helsinki, and we invited Sergey to Dyalog ’24 to tell us more about this project. When completed, the APL MOOC will be an online APL course for university students, worth 5 ECTS credits (or 3% of a Bachelor’s Degree) to Finnish and other European students. You can review the work in progress, and send comments or words of encouragement to the team, at aplmooc.fi.

Data Science is a term that – along with artificial intelligence – is used to describe a very wide range of data processing techniques, from cross-tabulation and standard statistical techniques over regression, to large and small “language models”. The other three talks released this week look at the use of APL as a tool for Data Science from different perspectives.

In his presentation Dyalog for Data Science, Jesús Galán López compares APL to popular Python libraries, solving some well-known introductory problems in what used to be a statistics curriculum but is now called Data Science. As he concludes: “If you are an APLer and you have been using APL to extract useful information from data: Congratulations, you are a Data Scientist! And if you are a Data Scientist – Try APL!”.

Stephen Mansour is the creator of TamStat, an application written in Dyalog that he uses to teach statistics to University students. A core component of the design of TamStat is the use of defined operators to create a domain-specific notation that is not only flexible and powerful but makes the fundamentals of statistics easier to grasp – hence the name “Taming Statistics”. His presentation on Taming Regression using APL illustrates how, by designing user functions and operators to be similar to APL primitives, you can produce a notation that is a user-friendly Tool of Thought, helping you to understand statistics in ways that are close to impossible in other languages. In addition to being available as a free application, the source code of TamStat is free and open source, and available for use in your own applications.

Not all data science applies to rectangular data that can be easily grouped and cross-tabulated. In 2015 I did a presentation in the Talks at Google series. Towards the end of my presentation, I was asked about Iverson’s original intention of having APL natively apply to arrays and trees…”What happened to the latter?”. Arthur Whitney was in the room, and I asked out loud “What happened to the trees, Arthur?”, to which he responded “I don’t know” and can be seen shaking his head. I then waffle on a bit about nested arrays and how they lead to poor performance. Today, thanks to Aaron Hsu, I have learned that regular flat APL arrays allow for extremely efficient representations of trees (his thesis on the co-dfns compiler shows that this can be used to achieve orders-of-magnitude improvements in performance in compilers). In his presentation Climbing Trees and Catching Bugs, our Senior Intern (spending his second consecutive summer with us!) Asher Harvey-Smith introduces a tutorial that he is working on, with the goal of making Aaron’s techniques easily approachable to newcomers. He also talks about some of the other fun he had this summer.

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

This week’s videos:

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

Dyalog ’24 Videos: Week 2 – New Functionality

The recordings released this week focus on active development projects at Dyalog Ltd.

The first three presentations describe features that are expected to be in the next version of Dyalog. In Setting and Getting Variable Values Mk II, Adám Brudzewsky describes a set of new system functions for setting and getting variables’ values using arrays. Until now, this required the use of the primitive function execute (), in ugly and inefficient expressions. Also, execute is increasingly seen as a potential security risk, as careless use allows code injection attacks – so these new Dyalog v20.0 features will not only increase the readability and performance of application code, they will also make applications more secure.

John Daintree returns with WC Plugins. This is not a talk about tools for unclogging drains, but a general mechanism that will allow both the Dyalog development team and users of Dyalog to create self-describing libraries in C, which the ⎕WC (and ⎕NEW) system functions will be able to create instances of, in the same way that they can currently be used to create GUI objects and OLE or OCX components. This will allow us to open-source parts of the Dyalog interpreter, such as our HTMLRenderer interface to the Chromium Embedded Framework, the Conga interface to TCP and UDP, and an upcoming cryptographic library. It will also make it easier for users to contribute to the Dyalog ecosystem.

Peter Mikkelsen is one of the youngest members of the Dyalog development team. In New Function for Shell Calls, he describes the work that he has done to create a modern version of one of the oldest system functions in Dyalog APL – the ⎕SH function for making shell calls (known as ⎕CMD under Microsoft Windows). Among other things, this new function can be interrupted and can run the shell command on a separate operating system thread. It allows you to separate and redirect output streams, and specify what encodings are used. It even allows you to stream output to and from the external code asynchronously, using tokens and callbacks. It is slightly surprising that it cannot make toast!

The other two recordings this week are about features that are already available, but more people need to know about!

Adám Brudzewsky shows how text files containing APL code or data are all that you need to define and run an application in Initialising and Starting from Text Files. You can also extend your APL development environment with a few text files in the right place!

Finally, in New Tatin Packages, Brian Becker reintroduces the Tatin package manager, and describes three new Tatin packages that Dyalog Ltd have recently made available – a package for loading and using .NET packages hosted in the NuGet system (dyalog-NuGet), a package for managing APL processes in the same way on all platforms supported by Dyalog (dyalog-APLProcess), and a somewhat experimental package for tapping into the OpenAI platform and generate images, have conversations with large language models (LLMs), and access other “Artificial Intelligence” features (dyalog-OpenAI).

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

This week’s videos:

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