CodeBot for Delphi is out now! What is it, why did we build it, and how can it help you, your projects, and your business?

We built CodeBot because the world is changing. A year ago, when we began, it was already very obvious that coding was changing. Where would Delphi be?

We care about Delphi and Delphi developers. We want it to succeed.

CodeBot is a complete coding agent. It is not a wrapper around another coding agent: it is a coding agent.

And it is one built especially for Delphi: answering the question, what if instead of a generic AI that worked well for Python, TypeScript, Rust, and the web, a coding agent was built with Delphi first in mind? Not only in its knowledge, but in its design?

• CodeBot is able to work with forms, frames and data modules, with them open in the designer – because visual preview is core to Delphi.
• CodeBot understands visual design rules, like alignment.
• It shows its work, in text, diffs, and even 'visual diffs':

• It's aware of your project and project group, as well as the third-party components and libraries you use.
• It knows about modern Delphi, and will write different code when it's installed in Delphi 11, 12, or 13.
• ...and more.

On top of all this it is a highly capable coding agent on its own, capable of understanding your codebase, modifying existing code (and forms), creating entirely new features, and analysing for potential bugs.

We support everything you would expect, including  Skills and MCP, but have several unique Delphi-focused features. We also let you track what CodeBot does, and have a documented security and permissions model.

CodeBot itself has a data policy, which is suitable for sending to your Legal or Approvals departments. This data guarantee (this includes your source code) applies no matter your usage of CodeBot or plan: a home hobby user or a larger enterprise both get the same data privacy.

We're grateful to Embarcadero for sharing CodeBot, in two separate webinars during development!

Architecture and Subscription

As developers you probably want to know how CodeBot works, and why it works the way it does!

Architecture

The most important point about CodeBot is that it is a full coding agent in its own right.

There is a client. This is a lightweight frontend that lives in Delphi itself, and is written in Delphi. It manages the IDE: handles file read and writes, sandboxes them, handles form/frame/data module editing, etc. CodeBot could have any client so long as it understands the network protocol, which is a series of JSON packets plus a regularly renewed message stream. The client also renders the chat history; all text is sent as Markdown.

The server is where all CodeBot logic lives. It's a separate layer from the client for several reasons:

• We can update behavior quickly and easily. If a bugfix or new feature had to wait for a client-side update, people might not get it very often, and multiple people might all have different behaviors. A quick server redeployment means something new can arrive to you fast.
• It allows us to safely implement billing (we refer to this as usage, if you see this in other docs)

The server is implemented in Oxygene Pascal, using the RemObjects web server, deployed to .Net on Linux. This allows us to use Oxygene features and syntax.

The server also uses our upcoming AI Infrastructure library, which was built for the many uses of AI in our products: a version of CodeBot in Fire and Water, change set analysis in GitBrowser, and more. CodeBot is one of the most demanding consumers of the Infrastructure SDK, and Infra will let you build multi-agent platforms just like it.

Inside the server, CodeBot is a multi-agent architecture. Dispatched messages are routed to various specialized agents, and can route between each other or to subagents for delegated work. Although specialized, they share a common identity and memory between them. This lets us tune behavior for various tasks: coding, visual design, planning work, researching codebases, and more.

Based on the task and the intelligence level you select, we use different models. Currently, all are OpenAI. We will continue to adjust the models and behavior to give the best Delphi coding possible.

Subscription and On-Premise

Because CodeBot is a full coding agent, it provides AI usage as part of its cost, and it does not require a secondary subscription.

Its behavior has been very carefully tuned for the AI models it uses: if you give it other models, it will behave differently. Even different models from the same provider can behave very differently, let alone a completely different one.

It's a subscription because it costs us to provide the service every time you use it! CodeBot cannot be a once-off purchase.

We have subscriptions for a wide variety of usage levels. If you hit the limit for your plan, you can also top up.  

Cool Stuff

Too much to list.

• The first time we saw the form changed by an AI live in the IDE designer - wow.
• And we solve issues there from other AIs. Ever edited by AI and then got a runtime error because something was invalid in the form or form/pas sync? Not with CodeBot. (Remember: Designed for Delphi.)
• Autopilot. CodeBot's special mode for long-running work that does not require your attention.
• Sandboxed file system access. We run a middle ground between overcautious clients that require every single thing to be approved, and the wild west of system access. Within strictly defined limits, CodeBot can read and write; it will show you everything it did; and it's sandboxed via our client's file system security.
• Helpful. CodeBot's personality and behaviour is tuned by us. We hope you like it :)

Most importantly – once bootstrapped, CodeBot has partly built itself. We even share the prompt we used for one part of it (when CodeBot built its own slash command UI).

Install CodeBot!

• Main CodeBot page
• Prices (yes, we include AI usage!)
• CodeBot documentation, including Where To Start
• Built for Delphi – what makes CodeBot different
• CodeBot for Managers and Purchasers – send this to those who need to approve buying CodeBot!

Download the CodeBot for Delphi installer here (requires you to be logged in or create a RemObjects account.)

We hope you enjoy using CodeBot!

We shipped a virtual smorgasbord of stuff last Friday. Let's have a look.

Units of Measure

This is one of the coolest language features we ever added to Oxygene, and it will eliminate a whole class of bugs and allow for more intuitive code and APIs, especially, but not only, in the scientific community. We have a whole blog post covering it. Adopting it across Elements RTL and RemObjects Infrastructure already let us catch at least two separate bugs regarding seconds vs. milliseconds.

CodeBot for Delphi

But the star of the show this week is CodeBot, more specifically CodeBot for Delphi. We have a detailed blog post, and a brand new introduction video you can watch on YouTube or RemObjects TV.

CodeBot Server Credits in GitBrowser and CodeBot for Elements

Both GitBrower and CodeBot in Fire/Water can now optionally connect to CodeBot Server, so you can use your CodeBot Credits insead of having your own OpenAI Key. This is especially useful if you're mainly a Delphi developer, but want to use GitBrowser's intelligence or have a first play with Oxygene.

GitBrowser for Windows

GitBrowser, our powerful and free Git GUI Client, which used to be Mac-exclusive, is now available in a fully native Windows version, made possible thanks to the cross-platform power of Elements and the coding skills of CodeBot, which did pretty much all the work in a weekend.

Fire on .NET Core (Preview)

As you may know, Fire, our Mac development environment for Elements, is a truly native Cocoa app written in Elements itself. But it uses Mono under the hood to host the compiler and IDE smarts that drive features such as Code Completion, Refactoring, Go-To-Definition and more. That's because the compiler itself is pure .NET.

Mono, alas, has been deprecated and unmaintained for a while, and the .NET platform has evolved and moved on from classic .NET as well, with .NET Core.

This week, we're shipping two new builds of Fire.

• Build .3101 is the normal Fire you know, same as always, except of course with all the new goodness that's in this week's version of Elements.
• Build .3103 on the Experimental channel has all the same features, but instead of Mono uses .NET Core 10 to host the IDE smarts. It ships with the same .3101 compiler.

Getting Fire to .NET Core was no easy feat; it involved a full port of Marzipan, our open source Mono/Cocoa bridging layer, to support .NET Core. It also involved a significant rewrite of our .NET Core debug host, which used Windows-only APIs, to now run on Mac (and Linux).

I've been using Fire/.NET Core for a while now as my main system, and all seems to be working fine. But your testing and feedback would be appreciated before we merge this into the main line, probably in a few weeks.

Fire, of course, will still support building and debugging apps for Mono and Classic .NET 4.x. In fact, it will keep shipping its current bundled dual-architecture Mono runtime for a while, to make it easy to still run Mono/arm64 projects. Probably for as long as Mono keeps working on macOS...

Earth for Linux (Early Preview)

Lastly, speaking of platforms, we have another small little thing that shipped as a very early first preview this week; it's called Earth, and it runs on Linux.

We'll talk more about Earth next week, but if you have an active Elements subscription and you work on or are interested in working on Linux, you might want to have a peek at the Experimental channel downloads for it.

This week's Elements build adds a major new feature that I personally have been dreaming of adding to Oxygene for well over a decade; we just never got around to it. Well, now we did.

One of the great things about Object Pascal (and other true OOP languages) is that it is strongly typed. You cannot just assign a String to a Button, the compiler won't let you. This leads to safer code that is validated at compile time rather than at runtime. But there's one area where Object Pascal has let us down until now, and that is numbers. Numbers can mean a great many things. 100 can be a lot, or really little, depending on context.

Let's just take one common example: fEvent.WaitFor(aTimeout: Integer);. Ok, cool, but what unit is this integer in? Will it be too quick if I pass 1 because it's milliseconds, or will it wait forever if I pass 1000, because it expects seconds? Who knows 🤷‍♀️. Maybe it's in the documentation. But the compiler certainly has no idea, and can't help you.

Until now.

Oxygene 13 adds two new fundamentals to the language: dimensions and units.

A dimension is the abstract concept of something that can be measured by a number. For example, distance. A unit is a concrete, well-defined way to measure a dimension. For example, meters. Or furlongs. Or football fields, if you're American.

type
  Distance = public dimension(Double);
  Meters = public unit(Distance) as m;
  Yards = public unit(Distance) as yd;

This code defines a new dimension that represents distances, as well as two concrete units.

var x: Meters := 5;
...
var y: Yards := x;

In the past, we'd have a problem here that we'd not find out about until someone runs our app and notices that the numbers are off by 0.9144. Not ideal. But now that we have strongly-typed units, the compiler knows your code is about to mess up, and can do something about it.

But what? The simplest idea would be to warn (or error) to let you know about your mistake. But we can do better than that! What if instead Yards were defined as follows?

type
  Yards = public unit(Distance) as yd = 0.9144m;
 

Now the compiler can do more than just err. The compiler can actually make your code work as intended by converting from meters to yards, for you.

Let's go back and redefine our WaitFor method as such:

method WaitFor(aTimeout: Milliseconds);

The compiler now knows what exact unit the method expects, and can enable us to call it with the unit that we find convenient when calling it:

var DefaultTimeout: Seconds := 30;
...
fEvent.WaitFor(DefaultTimeout);

The call site is clearly stating its intention – not to wait for 30 whatevers, but for thirty seconds, specifically. The method clearly states that it works with milliseconds. This allows the compiler to do the rest, and convert your "30" into "30000".

Full Unit Syntax

There are four parts to a unit definition:

type
  Distance = public dimension(Double);
  LightYears = public unit(Distance) as ly = 9 460 730 472 580 800m;

• First, the name.Lightyears defines a new strong numerical type that is at runtime backed/represented as a 64-bit floating-point double.
• Then, Distance establishes the unit as part of the Distance dimension. Units of the same dimension can be compatible with each other (as we've seen above for Meters/Yards and Seconds/Milliseconds. Even if a unit mismatches, the compiler knows whether the two values even represent the same concept or not.
• ly provides an (optional) shorthand form the unit that can be used in constant expressions: DistanceTraveled := 2ly;
• Finally, a conversion path can be provided between different units in the same dimension. Here, we tell the compiler that one light year is about 9 and a half quadrillion meters. That's a long way home.

Any two units for which the compiler can find a conversion path (whether direct or indirect) can simply be assigned to each other. Assigning, e.g., a mile to a centimeter, and the compiler might go from mile to yard, to meter, to centimeter, if the following units are defined:

type
  Centimeters = public unit(Distance) as cm = 0.01m;
  Meters = public unit(Distance) as m;
  ...
  Yards = public unit(Distance) as yd = 0.9144m;
  Miles = public unit(Distance) as mi = 1760yd;

You can even do var Distance := 5km+5m+1mi.

Note: If you like, you can define multiple units in the same dimension w/o a well-defined conversion factor. You will still get the benefits of unit type safety; you just won't get automatic conversion. For example:

type
  Refrigerator = public unit(Volume);

No one except TV newscasters really knows what "the size of 10 refrigerators" actually means, but at least now it won't accidentally be mistaken for a proper unit such as, say, cubic meters 🙃.

Another cool unit to have is

type
  Temperature = public dimension(Double);

  Kelvin = public unit(Temperature) as K;
  Celsius = public unit(Temperature) as °C = value + 273.15 K;
  Fahrenheit = public unit(Temperature) as °F = (value + 459.67) * 5 / 9 K;
  Rankine = public unit(Temperature) as °R = value * 5 / 9 K;

Now you can do:

var c := 35ºC;
writeLn(#"c {c}"); // 35 ºC
writeLn(#"c {c as Kelvin}"); // 308.15 K

Or, if you must:

  writeLn(#"c {c as Fahrenheit}"); // 95 °F

And yes, you can use º in a unit name, just fine.

Dimension Relationships

Things become more interesting when more than one dimension is defined, and we teach the compiler the relationship between them:

  Time = public dimension(Double);
  Speed = public dimension(Distance/Time);
  Acceleration = public dimension(Speed/Time);
 
  ...
 
  Seconds = public unit(Time) as s;
  Minutes = public unit(Time) = 60s;
  Hours = public unit(Time) = 60 Minutes;
  ..
  MetersPerSecond = public unit(Speed) as mps = m/s;
  KilometersPerHour = public unit(Speed) as kmh = km/Hours;
  MilesPerHour = public unit(Speed) as mph = mi/Hours;

We can now do

var lDistance := 5km;
var lTime := 30s;
var lSpeed: KilometersPerHour := lDistance/lTime;

and despite lTime being provided in seconds, the result will be in km/h!

More importantly, even without the explicit type, the compiler would derive that var lSpeed := lDistance/lTime should be a Speed type (it would just pick a different default unit, probably).

This becomes more fun, the more complex the relationships get. For (maybe a bit of a contrived) example, here x will be strongly typed as GravitationalConstantUnits.

  var l := 2.0m;
  var mass := 500.0g;
  var time := 3.0Hours;

  var x := l*l*l/(mass*time**2);

simply because the compiler has been told that unit is defined as m**3/(kg*s2):

type
  GravitationalConstantUnits = public 
 unit(GravitationalConstantDimension) = m**3/(kg*s2);

Unit Conversions

As seen above, a unit can be defined in relation to a different unit of the same dimension (or even a different one, in some cases). This can take several shapes:

With a simple conversion factor

Simply using a unit expression of a sibling unit, with a value, can define a conversion factor. The value will be understood to represent 1 of the new unit. One km is 1000m. Once cm is one hundredth of a Meter.

  Meters = public unit(Distance) as m;

  Centimeters = public unit(Distance) as cm = 0.01m;
  Kilometers = public unit(Distance) as km = 1000m;

  Feet = public unit(Distance) as ft = 0.3048m;

With a more complex expression:

For some units, conversion not as simple. You can define a more complex conversion expression using the value keyword to express how a value of the new unit is converted to a different sibling unit. For example, by adding 273.15 K to the ºC value to go to Kelvin.

  Kelvin = public unit(Temperature) as K;
  Celsius = public unit(Temperature) as °C = value + 273.15 K;
  Fahrenheit = public unit(Temperature) as °F = (value + 459.67) * 5 / 9 K;

Once defined, these work both ways, e. g from ºC to ºF and back from ºF to ºC.

Via Base Units

For units derived from other base units*, you can also use the base unit in the expression, e.g.:

type
  Area = public dimension(Distance**2);
  SquareMeters = public unit(Area) as m² = m**2;

Here, the SquareMeter unit is not defined by relation to a different Area unit, but as the square (or really, multiplication of two) Distance units, Meters. Note how this matches the definition of the dimension, which is declared as Distance**2. (** is the power operator in Oxygene, e.g. Distance²)

As Reciprocal Relationship

Finally, a unit (and its dimension) can be defined as the reciprocal (or inverse) of a different unit. For example, frequency is the number of <somethings> per unit of time:

type
  Frequency = public dimension(1/Time);

  Hertz = public unit(Frequency) as Hz = 1/s;

* We consider a base unit the unit that all others are derived from. E.g. in the examples above, Meters is the base unit, while Centimeters or Yards are derived from it. In many cases, the choice of base unit is arbitrary; one could just as easily have picked Millimeter as the base.

The same goes for dimensions. We have Distance and Time defined as base dimensions, while Speed is defined as the quotient of Distance and Time. That is the intuitive way to do it, but as far as the compiler is concerned, we could have declared Speed as a base unit Distance = dimension(Speed*Time). It'd be a lot more confusing, but just as valid.

As a final note here, the unit system is smart enough to understand the relationship between exponential expressions and multiplications. E.g. while area is defined as Distance**2 (i.e. Distance²), it knows that just means "Distance * Distance", i.e. any product of two Distances will qualify as an Area, and vice versa; the same goes for e.g. **3.

Units in Elements RTL

Units come to you in Oxygene 13.0.0.3101 in two ways.

First, it is a language feature that you can use to define your own units as you need.

Secondly, and I think more interestingly for most users, Elements RTL comes with a huge list of predefined units in the RemObjects.Elements.RTL.Units namespace. Just reference the library (you should anyway), and add the new namespace to your uses clause, and you have immediate access to several dozen dimensions and units, including all the examples shown here, many more derived units in the same dimensions (eg mm, cm, km), as well as units for many common physics, chemistry and electro-technical domains such as Mass, Force and Pressure, Speed, Acceleration and Momentum, Power and Energy, Voltage, Amperage and Resistance, Radioactivity, and many more.

If you define your own units, we would strongly sugest to build on what's in RemObjects.Elements.RTL.Units. But you can, of course, also just define your own, independent unit space.

Finally, if you think we missed any obvious or (more likely, given the broad coverage) not-so-obvious units or dimensions for your favorite domain in our default list, please do not hesitate to let us know, and we will expand the list.

You can have a look at Units.pas to get inspired by what's already there and to consider how you can apply it to your projects, as well as to see examples for more complex and esoteric unit definitions, such as KilogramSquareMetersPerSecond.

Get Build .3101 or later of Oxygene 13 now.

Units are new in build .3101. Get it now, as a free trial download or as a free update for all active subscribers!

One of the things we always strive for our tools to do is meet you where your work already lives.

For most developers these days, that means Git, of course, but it also means GitHub or GitLab. Your source code is there. Your issues are there. Your pull requests or merge requests are there. CI status, releases, tags, milestones, labels, all the little bits of project state that live around the actual code — they are there too.

So with this week’s builds, we started to make Fire, Water, GitBrowser, and CodeBot a lot aware of those services.

You can now add GitHub and GitLab accounts in the Account Manager, including custom/self-hosted GitLab installs, and both GitBrowser and CodeBot in Fire/Water/Campfire can make use of them.

GitBrowser

The first place this shows up is GitBrowser.

Until now, GitBrowser mostly assumed that the repositories you cared about already existed locally. You could add a folder, drag a checkout in, group your repositories, work with local changes, branches, worktrees, commits, pushes and pulls, and so on.

That is still the core of GitBrowser. It is, first and foremost, a really nice tool for working with your local Git checkouts. But now it can also help you get those checkouts in the first place.

Once you have added a GitHub or GitLab account, the “Clone Repository...” flow can show repositories from that account. Pick one, choose where it should go, and GitBrowser will clone it and add it to your sidebar. SSH is the default, because that is what most of us use day to day, but HTTPS is available too.

This also works for custom GitLab servers, not just gitlab.com. So if your team runs its own GitLab instance, GitBrowser can talk to that as well.

The other direction is publishing.

If you have a local-only repository — maybe you initialized a folder locally, or dragged in a project that was not under Git yet and let GitBrowser initialize it — GitBrowser can now help publish it. You can publish to:

• a remote URL you already know,
• an existing empty GitHub/GitLab project,
• or a brand new GitHub/GitLab repository.

New repositories default to private, because that seems like the least surprising and least embarrassing default. You can choose the owner or namespace, enter the repository name, pick the branch to push, and GitBrowser will create or connect the remote, add origin, and push with upstream tracking set up.

One small but important detail: GitBrowser tries to infer GitHub/GitLab relationships from your existing remotes. So if you cloned a repository outside of GitBrowser, it should still be able to recognize “this is a GitHub repo” or “this is from that GitLab server”, and offer useful actions such as opening it on the web.

This is the beginning, not the end. Once GitBrowser knows about your account and can match a local checkout to a hosted project, a lot of future niceties become possible: creating pull requests or merge requests, checking out PRs into worktrees, showing CI state, opening issues, and so on, are on our list next.

But cloning and publishing felt like the right first step. Nice, practical, and immediately useful.

CodeBot in Fire and Water

The second place this shows up is CodeBot.

CodeBot already understands your solution, your code, your build errors, your debugger session, and so on. Now it can also understand the project-management side of the work, using the same GitHub and GitLab accounts you configure in the IDE.

That means you can ask CodeBot things like:

What issues are open for this project?

or:

Can you look up issue #1234?

or:

Log a new issue for this bug we just found.

CodeBot sees a unified tool surface, regardless of whether the backing service is GitHub, GitLab.com, or your own GitLab install. You do not have to think in terms of GitHub’s API shape versus GitLab’s API shape. CodeBot asks for “issues”, “pull requests”, “labels”, “milestones”, “pipelines”, “releases”, and so on, and the provider-specific details stay hidden behind the scenes.

For this first round, CodeBot can work with:

• configured GitHub and GitLab accounts,
• project/repository connections for the current workspace,
• issue lookup, search, creation, updates, and comments,
• pull requests and merge requests,
• labels and milestones,
• projects/boards where the provider supports them,
• CI/pipeline/status information,
• releases and tags.

Write operations still go through CodeBot’s approval system, so if CodeBot wants to create an issue, comment on one, or change something in your project tracker, it will ask first and tell you what it is about to do: which provider, which account, which repository, which item, and what change.

That is important. Reading project context is one thing. Writing to the team’s issue tracker is another. Helpful automation is great; surprise automation is not.

Under the hood, this is built as native account support rather than MCP. MCP is still great, and CodeBot continues to support it, but for GitHub/GitLab we wanted this to feel like a first-class IDE feature: accounts live in the Account Manager, credentials are stored securely, and the same connection can be used by GitBrowser, CodeBot, and future IDE features.

As always, this is one of those features where the first version is useful, but the real payoff comes as it starts connecting with everything else.

Imagine asking CodeBot to investigate a failing build, trace it back to a commit, look up the related issue, summarize the current PR, and then draft a comment with what it found. Or having GitBrowser show you not just that your branch is ahead, but that the matching merge request is green and ready to go.

That is the direction we are heading.

For now: add your GitHub or GitLab account, try cloning and publishing from GitBrowser, and try asking CodeBot about your issues.

And, as always, let us know what feels useful, what feels awkward, and what obvious thing we forgot.

We only shipped GitBrowser for Mac earlier this year (after it being an internal tool here at RemObjects for several years), but it has already evolved a lot since. Let's take a look at some of the exciting new features we recently added...

Change Set Analysis

One of my favorite features that recently landed, and frankly one I cannot even believe I lived without, is Change Set Analysis.

These days, I don't just work on my local checkout alone. Between CodeBot and Codex, I often have several agents working on adding new features or improvements at the same time, while also tweaking and reviewing code myself. After a while, I easily end up with 30+ changed files covering different sets of features, all ready to be reviewed and committed. (Yes, I should be using separate branches, see below 😉. But often I don't, because often it's easier not to).

GitBrowser's new Change Set Analysis makes it easy to sort out what's landed, review it, and commit it clean.

Simply right-click in the empty space of your changed files list, and choose "Analyze Changesets with CodeBot". GitBrowser will gather all local changes, and pass them to CodeBot to analyze, and after a few seconds, you get a view like this:

CodeBot has grouped my 20+ changes into distinct groups, and provided me with a succinct description of what each changeset entails. In this case, there's a new "code completion" for the prompt editor (think typing voice=), changes to the history chat compression, and some more changes off-screen.

Clicking on any of the filenames will give you a diff preview via QuickLook.

If I'm feeling confident, I can click "Commit" right there, confirm and/or adjust the pregenerated commit summary, and done. More often than not, instead I'll choose "Stage This" and close the sheet. GitBrowser ill stage the relevanr changes for me – and prefill the commit message – but i can then have a peek at the files, review the changes, and see if i maybe want to include or exclude anyting else form this change, before i commit manually.

In the example shown here, the changes were to several pretty distinct features, so there was no overlap. But the cool thing with Change Set Analysis is that it works even if parts of a single file have changed for Feature A, and others for Feature B. When you tell it to stage (or commit) Feature A, you will see that the file shows in a partially staged state – GitBrowser has committed only the sections that belonged to Feature A, but not the ones for Feature B.

Pretty cool.

Partial Staging or Reverting

GitBrowser has also gotten support for manually staging just parts of a file. Again, this is helpful if, e.g., you made changes to a file that cover distinct features, but also if you maybe have some changes that are ready to commit while others are not, or you have unrelated local changes – e.g., debug logging – that you don't want to commit.

Right-click in the diff view at the bottom right of GitBrowser, and you can now choose to stage (or discard) any individual change (or hunk, as Git calls them).

In this case, I'll discard the change, because importing Foundation is silly when AppKit is already in use. Even Codex doesn't get it right all the time... ;)

If a file is partially staged (showing as [-]), a new toggle at the bottom of the diff view lets you choose which diff to see: previous version vs. staged, or staged vs. unstaged. (If a file is fully staged or fully unstaged, the toggle is disabled – because one of the diffs would be empty. But it still adjusts to show you which view you are looking at.

Double-clicking your file to open an external diff viewer will open a three-way diff (if supported), allowing you to compare the previous version, staged, and unstaged, at the same time (this part is not new).

Worktree Support

I'm somewhat new/late to using worktrees, myself, and you will argue that embracing them more fully would prevent needing Change Set Analysis. And you'd be right, but.

In Git terminology, a Worktree is similar to a branch being checked out to its own separate folder, except that it is not, in that it doesn't require you to have a complete separate clone of the repo, and that Git keeps track and manages your wlorktrees for you. GitBrowser embraces worktrees and makes ot really easy to work with and manage multiple worktrees for your repository.

Personally, I'm not a big branch guy myself. I will use branches (and worktrees) for big, long-running feature work, but I prefer to stay on my main branch for regular development. Hence, Change Set Analysis ;).

Getting started with worktrees in Git Browser is super easy. You can create a new worktree in two ways, from the Branches pop-up in the toolbar

• Open the "Worktree from Branch" submenu, and pick any existing branch.
• Choose "New Worktree..." and pick a name for a new branch, to create a worktree based on your current branch.

Note that you can only create a worktree for a branch that is not currently checked out, and once you have a worktree for a branch, Git will not allow you to switch to that branch on your main checkout or on any nother worktree. GitBrowser will gray our ineligible branches in the menu.

In either case, GitBrowser will ask you for a target folder for your new worktree. It will suggest your main repository folder, suffixed with the branch name, e.g. ./MyApp-develop-coolnewfeature so the new worktree would live next to the orogonal folder – but you can place your new worktree anywhere on disk that you like.

Once a worktree exists, you can work in that folder like you always would. You can commit, you can push, you can merge e.g. your master branch back into the worktree branch, and so on. It behaves like a normal Git checkout. You can even switch branches (which might get confusing if you named your folder after the branch, so I don't recommend it), as long as that branch isn't checked out elsewhere.

Git and GitBrowser keep track of your worktrees, and if you do have any active worktrees, they will show up as child nodes of your repository. They will also show in the branches pop-up in the toolbar.

Your main checkout will show with the solid tree icon, and it represents the main folder of your repository, the actual git clone. Secondary worktrees will show as the hollow tree icon.

Selecting any worktree in the list will allow you to work with that worktree and on that branch in GitBrowser, as if it were a normal checkout (which it is, I guess). You can review your changes, stage and commit, browse history, run available merge scripts, and so on. (Selecting the "solid tree" main checkout is the same as selecting the root node).

The context menu for worktrees provides some additional helpful options. "Compare to" opens your favorite diff viewer for a folder comparison between the two worktrees and any other. It's helpful if you just want to have a quick peek at what's different, or maybe review a change made in the branch compared to the original code.

More interestingly, "Analyze Changes over" allows you to run a full Change Set Analysis (similar to above) between the two branches. Like for local changes, Change Set Analysis will ask CodeBot to have a detailed look at the files that differ between the two worktrees, and give you summaries of the changes in logical groups.

It's super helpful if your co-worker just dumped a branch on you to merge with seven new features that need to be reviewed and approved before they can be merged. Not that that ever happened to me...

Finally, at the bottom of the context menu, there's an option to "Retire" the worktree once you're done with it. Retiring will delete the local folder (but not the branch!), and will unregister it with Git. You should generally not just delete the folder manually, because then Git will not know about it and get confused. But if you did, GitBrowser will detect that, show your worktree as "missing", and give you an option to clean things up.

As a last aside, you might notice the two odd worktrees in the screenshot above, and might find similar one slisted on your system. Worktrees can be checked out to a name branch or a commit, and – unlike with branches, several worktrees can exist for the same commit. The two you see here were created automatically by Codex for background work. It will sometimes do that. You can delete them in either GitBrowser or via Codex's Preferences view, if you are sure they aren't needed anymore.

GitBrowser for Windows

GitBrowser was originally conceived as a Mac app, because I wrote it mainly for myself to use when GitBox died.

Since we shipped it, a lot of people have asked to use it on Windows, so here we are.

GitBrowser was actually built on the same IDE foundation as Fire, so porting it turned out to be a lot easier than expected (or maybe just as expected) – it was basically a weekend side project to get a usable v0. We have done a lot more polishing since, and a lot more is to do, but as of this week's .295 set of builds, a preview build is available for download. Check it out and let us know what you think!

GitBrowser and CodeBot Server

Finally, I want to talk about a new option for connecting GitBrowser to AI.

Right now, GitBrowser uses embedded CodeBot – just like Fire and Water, if in an exposed, much more limited way – for its AI functionality. This means you provide it with your own API key to connect it to the AI provider of your choice, e.g. OpenAI, Claude, or Gemini.

With the upcoming CodeBot for Delphi, which uses our own CodeBot Server backend, you will now be able to connect GitBrowser to your CBS account and your existing CodeBot/Delphi credits for the AI features – no separate sign-up with an AI provider needed. In the back, CBS uses OpenAI's gpt models.

The main theme this week is that CodeBot has evolved further, from a reactive chat assistant toward something more proactive, media-capable, and host-aware. In particualar for the upcoming Campfire, this shows up as scheduled prompts, proactive reach-out from CodeBot to you, and new options for time awareness, location awareness, life events, and proactive planning. CodeBot also now keeps long-running work awake with power-management support, which should make longer background runs more reliable.

Media generation is the other big visible area. CodeBot and Campfire gained broader image generation routing, partial media previews, generated-image annotations, and early video-generation support via Grok and Gemini, including retries, partial-result recovery, streaming image support, reference-image persistence, and generated-media cost tracking.

On the compiler side, Elements had a more focused but still meaningful quality pass. The compiler picked up fixes for invalid IL around untyped var params in async state-machine cases, stack-depth verification after raise in case expressions, fixes for C# string interpolation whitespace, Java file-scoped package preservation, Delphi Compatibiliti Mode enhancements, and stricter handling of untyped var/out params outside DCM. The debugger also gained delegate-variable support on the CLR and Mono.

Infrastructure carried much of the platform work behind the Fire/Campfire changes: persistent scheduled prompts, proactive planner diagnostics, duplicate-schedule protection, thread-history chaining for better conversation context, safer skill/session refresh behavior, stronger model-strategy propagation, image-generation capability gating, and more robust analyzer parsing.

Elements 13 shipped just last week, but we already have a major new round of features and enhancements landing today.

Fire & Water

• CodeBot got broader model strategy/profile work: deep reasoning profile, debugger profiles, capability-based model selection, Mistral/latest model strategy, better routing, and public orchestration enablement.
• Interactive debugging mode for CodeBot in Fire and Water.
• MCP support in CodeBot expanded with endpoint connection UI, OAuth flow support, optional local approvals for access to the MCP Server, and safer elicitation behavior.
• CodeBot also gained image generation support (less interesting for CodeBot, more intersting for the upcoming Campfire).
• Usage reports for CodeBot if Fire, Water and GitBrowser.
• GitBrowser gained CodeBot-assisted changeset analysis for unstaged diffs, and support for logical grouping of files/hunks.

Elements

• Toffee/libNougat LINQ support expanded substantially: Chunk, SkipLast, TakeLast, Zip, Append, Prepend, Aggregate, LongCount, joins/group joins, SelectMany, SequenceEqual, DefaultIfEmpty, ElementAt*, Single*, Count(block), Sum, Average, ToLookup, and corrected Except semantics.
• InternetPack updates inside Elements: percent-decoded HTTP query parameter names/values, bound-port reporting after socket bind, and consolidated multi-target project structure.
• RTL2 update: async Process completion is more reliable when output pipes stall, on Darwin.

CodeBot for Delphi

• CodeBot for Delphi is getting closer to release, with a new client build that lands a lot fixes and improvements and, more importantly, a brand new Code Bot Server backend built on the shared Infrastructure Agent Runtime.

Infrastructure

• OpenAI integration advanced quite a bit: /responses API support, image generation support, automated API key creation tweaks, usage/cost APIs, and gating/routing around newer model capabilities.
• Structured JSON response formats are now supported across AI clients and agent profiles, including OpenAI chat/responses payload handling and tests.
• Model routing became more capable: configurable model strategies, reasoning effort tracking, capability fallback routing, profile-level capabilities, explicit profile routing from message text, and better GPT model filtering.
• Agent runtime improved: AI usage tracking for runs, polished usage report presentation, cleaner profile/orchestration model, and revamped runtime overview documentation.
• Gemini tool calling support was added, and Claude request handling has been improved

High-level theme: this week is heavily CodeBot/AI-platform focused, with visible Fire/GitBrowser workflow upgrades, a sizable Infrastructure AI/MCP/OpenAI foundation push, and a smaller but meaningful Elements compiler/runtime/library fix batch.

But the most exciting thing, I think, is that CodeBot is now a painter too.

With last week's release of Elements 13, we shipped what is probably the largest and most significant update to CodeBot since its inception: CodeBot v3.

CodeBot v3 is not just an extension of what came before it; it is a brand new experience that will – I know this might sound like hyperbole, but trust me, it's not – change how you write Elements code, forever.

The biggest change to CodeBot is under the hood, and that it has grown from a simple question/answer chat model to a fully orchestrated agent runtime powered by RemObjects Infrastructure. It knows different profiles and can spawn agents specialized for certain tasks, such as code review, finding security flaws, writing new code for you, or even interactive debugging. Each specialized agent automatically comes with Skills embedded that give it expertise in its field, and in Elements in general.

Skills

Detailed, predefined skills for your language (s) and platform(s) of choice let CodeBot really understand what you are working with. For example, if you are working on a cross-platform C# project (like I do when working on Fire itself), Codebot really understands that C# does not just mean .NET, and knows how to apply Cocoa concepts, use Elements RTL, and so on.

The Skill infrastructure is open and extensible, and you can create your own Skills (or have CodeBot create them for you automatically) to teach CodeBot about your own projects, coding style, and preferences, or to give it detailed knowledge about your application domains. You can create skills right inside CodeBot, and it will also automatically pick up any project-level Skills you might have from other tools such as Codex or Claude Code.

Tools & Approvals

CodeBot comes with more and better tools than ever, for all areas of development. It is better at reading code and has gotten really good at updating your code. It can build or test the project for you, diagnose error messages, run external tools, and more.

As someone once said, with great power comes great responsibility, so CodeBot has a new granular approval system that puts you in charge of what CodeBot can and cannot do.

By default, CodeBot will have read-only access to your project, meaning it can look around and give you advice. It can look, but not touch. For any action that could have an effect on your project (let alone outside of it), CodeBot will ask for your permission, which you can grant broadly or narrowly, based on your preferences and your trust in the tool. For example, if you ask CodeBot to make a change in your project for the first time, you will see someting like this.‌                                                              

Note how, in addition to showing you the change it wants to make (more on that in a bit), it gives you several options:

You can allow this and future changes to this particular file, or to all files in your solution (or its folder). You can also choose whether you want to approve just this one change (it will ask you again for the next one), or if it can go ahead making changes on its own moving forward – either just for this coding session, or forever.

This approval concept applies across all actions CodeBot can take, and you can decide how much autonomy to give it. For example, I tend to want to review code changes, especially when working on important codebases, so I generally press "Once", here, but I'm happy to let CodeBot do tasks such as rebuilding my project or starting a debug session, without re-confirming each time.

YMMV, also based on what type of project you work on – e.g., a serious project vs an afternoon vibe-code session.

Of course, you can always review (and remove) all pre-approvals in the new "Manage CodeBot Data" sheet.

(P)reviewing Code Changes

You've already seen that CodeBot will show you a nice inline diff of the changes it plans to make, and that's great. But I often find these diffs hard to read – especially for more complex or intricate changes to an existing method flow. CodeBot gives you the option to open the diff in a real external diff viewer of your choice, such as Araxis Merge (my favorite), Kaleidoscope, or BBEdit.

What's more, if you like what CodeBot proposes, but are not quite happy with the final shape – e.g., the formatting is a bit off – you can tweak it in Araxis Merge, hit save, and when you come back to Fire or Water, your changes will reflect when you apply.

No need to track down the code to adjust it afterward, or ask CodeBot to make a minor adjustment.

Action Items

Oftentimes, especially when doing a code or security review, CodeBot might come back with a whole bunch of suggestions on what to fix or improve. Not for your own code base, of course, but code other people wrote. Sometimes it can be hard to keep track or tackle it all at once, so CodeBot has the option to log these as "action items", to keep track of, tackle one by one, or come back to later.

You can then ask, e.g., to address these one by one and mark them off the list.

Builds, Runs & External Tools

CodeBot can, of course, run a build for you and look at, diagnose, and address error messages. In fact, it will often suggest doing this on its own after making changes, to make sure the changes landed well, or make further tweaks and adjustments if the first fix didn't stick. It can also run your project, including in EUnit test mode to run your unit tests (which it will often suggest to set up for you as it implements new features or fixes for you).

In addition, CodeBot can run (and manage long-running) external tools for you – after proper approval, of course. For example, you might be working on a project that connects to a separate server app. You could ask CodeBot to launch that server and keep an eye on its log output as you debug your app (or as CodeBot debugs it for you ;).

Debugging

Which brings us to Debugging. New in .3083 this coming week, CodeBot will be able to run a fully autonomous debug session for you, which is truly a sight to be seen. You can just tell it:

Hey, when I run my app, at point X in time I would expect it to print "blah", but it prints "blub". Can you debug and figure out why?

CodeBot will go ahead and debug this for you; it will run the project (sometimes many times), set breakpoints, step thru the revelant pieces of code, evalaute expressions – in essence, employ all the debugging steps you would normally do manually – and in the end, hopefully, not only point you to soucre of the bug, but also offer a ready-to-apply fix to solve your problem!

MCP Support

Model Context Protocol (MCP) is an industry-standard protocol for connecting AI tools, and CodeBot comes with built-in support for MCP both as a client and a server.

MCP Client support means you can connect CodeBot to your favorite MCP sources and access the external tools or resources provided by them. For example, you can connect CodeBot to our GitHub account via MCP and let it manage repositories or check and log tickets for you, or connect it to Notion to have it automatically generate documentation to share with the rest of your team.

MCP Server support means that CodeBot itself can (opt-in) act as an MCP server, and you can let other AI tools control Fire or Water for you. For example, you can connect Codex or Claude Code to Fire and have them run builds for you, understand the project content, or make changes for you. Essentially, any tool that CodeBot has at its disposal inside Fire or Water also becomes available to the AI apps you connect to it.

And So Much More

And these are just the highlights. There is so much more in CodeBot v3, anbd even more to come over the next few weeks and the rest of the year. We can't wait for you to try it!

Under the Hood

CodeBot v3 is built on our all-new Infrastructure AI Agent Runtime. It is a new shared codebase that will also be used by the upcoming (very soon now, promise 🤞) CodeBot for Delphi, and another in-the-works product, and is also available for use in your own projects, via our  RemObjects Infrastructure platform.

Get Elements 13 w/ the New CodeBot v3, Now

Elements 13 is out now and – as always – a free update for all users with an active subscription. Don't have a license yet? Get one in our also brand new and more beautiful-than-ever Online Shop, or get a free 30-day trial version to check it out!

Read more about CodeBot on its dedicated product page here.

Enjoy, and let us know how CodeBot changed your developing life!

If you compile your app for AVX2 and it runs on Windows ARM under Prism emulation, is it faster or slower than compiling for SSE2-4.x?

I assumed it would be roughly the same — maybe slightly slower due to emulation overhead, but AVX2's wider operations would compensate. The headline gives it away: I was wrong.

This post explains how I found out, what I measured and how, the benchmark results, and why.

Curiosity

A few weeks ago, in a Hacker News thread on WoW (the game) emulated performance on Windows ARM, I wondered:

I’ve been testing some math benchmarks on ARM emulating x64, and saw very little performance improvement with the AVX2+FMA builds, compared to the SSE4.x level. (X64 v2 to v3.) ... I’ve found very little info online about this.

Well, I nerdsniped myself, because those math benchmarks are now complete and so we have the perfect framework for testing AVX2+FMA emulation performance overhead on ARM Windows. I have no technical reason to do so: if you use our compiler we encourage that if you want to run your app on Windows ARM to just compile your app for Windows ARM. It's simply: I want to know.

Thus I spent much of Sunday crunching our data and figuring it out.

ARM emulation of x86

You can skip this bit if you know about Windows ARM's emulation and what various Intel instruction sets like SSE through AVX2 are: go forward to Benchmarks.

Windows 11 lets you run both 32-bit and 64-bit Intel apps on ARM. It does this via emulation. Essentially, x86/64 code is translated on the fly into ARM. Windows 10 supported emulating 32-bit Intel, and by 2021 Windows 11 introduced emulating 64-bit apps.

In 2024 Windows 11 was updated with a new emulation layer, Prism. The main user-facing change seems to have been performance: 'Microsoft told Ars Technica that Prism is as fast as Apple’s Rosetta 2' and:

Most x86 apps now run without issues, and in many cases don't even feel like they're being emulated. These days, the majority of users won't notice a difference between using an Intel PC or a Snapdragon one
– Windows Central

Is emulation complete / entire?

x86 and x86_64 have not always remained the same. Over time they add more functionality, which is exposed as instruction sets. These are the base instructions that an app can be compiled to use and are often focused around doing things faster. For example, the x87 floating point math instruction set still exists (it was introduced in the 1980s!) but was succeeded a quarter century ago by SSE2, introduced with the Pentium 4. SSE2 lets you perform floating point math operations much faster. A few years later the SSE 4.x series also improved largely integer-based operations. This is a very handwavy summary: in fact, these are part of a wide series of instructions intended to process data fast, where possible in wider configurations (more data at a time per clock tick) than older instructions, each new improvement introduced one by one over many years. This does not even begin to address the other supplementary extensions: ones for bit manipulation, specific math patterns like multiply-add, and more.

This is important to understand because software does not all use the same sets of instructions. Figuring out baseline standards of which sets it was reasonable for an app to use was a mess, and Linux folk found it annoying enough that, working together with Intel and AMD, Red Hat and SUSE defined standardised versions to allow known safe targets for compiling for specific collections of instruction sets. Thanks to them, x86_64 now has four main versions that modern compilers target, which define generations of new instructions. x64 version 1 is that same old year-2000-ish era; x64 version 2 circa 2008 level, v3 circa 2013 level, and v4 circa 2017 level.

It takes time for instructions to become mainstream: if you are building software for 64bit Intel Windows in general, you likely won't build solely for the v4 2017 level because you may have users who have older computers, or ones newer than 2017 but which had less capable chips that didn't feature all the latest instruction sets. AVX-512 (v4) is a wonderful instruction set for very wide vectorised behaviour but still many computers in practical use today don't have it.

And similarly to how actual hardware may or may not support specific instruction sets, Windows x86 emulation also supported only a subset.

That subset was approximately x64 version 2 (ie with SSE2 and 4.x) and only recently have newer versions of Windows have supported v3: to handwave, AVX2 and FMA. This is new, exciting, and to my knowledge, largely unknown.

We are comparing performance using x86-64-2 level vs v3 level running emulated on ARM.

That brings us to that Hacker News comment and today. What's the emulation performance for those newer instructions?

Our benchmarks

At RemObjects we make a multi-language (6 of them!) compiler toolchain that targets native CPUs via LLVM (as well as .NET, JVM, and WASM backends.) We recently integrated a new vectorised math library, which gave us the perfect benchmark framework for testing this.

We already supported ARM Windows, that is not new, but our cross-platform RTL had our own implementations of common math methods on the 'Island' (native) platform (the normal set: sin/pow/exp/floor and so forth.) These were correct in that they followed known algorithms, but we felt there was room for performance optimisation. We settled on integrating a third party open source math library. At the time I wrote the above HN comment, this integration was still being tested and tweaked; we even changed some of LLVM's internal passes.

Today, we have this new math implemented for macOS ARM (and x64), and Windows i386, x86_64, and ARM64. Our Windows 32-bit (i386) math supports SSE2/4.x, but the math library for Windows x64 supports using either v2 (SSE2-4.x) or v3 (AVX2-targeted) level depending on the x64 revision you target in the compiler options. (You can actually tell Elements to target v1 through v4, but our new math library kicks in at v2, with more performance with v3, and we have not enabled anything extra in math for v4; you can certainly compile allowing AVX-512 etc if you wish for your code in general though.)

As part of checking our new math code as (a) correct and (b) improved performance, we have concrete data running 21 different math operations on both real x64 hardware, and Windows ARM on Parallels on a Mac M2.

Because these are different machines we cannot compare the wall clock time, but we can compare the relative time, using the SSE2-4.x level as a basis: what is the relative performance difference of using AVX2(+FMA) on Intel vs on ARM? Normalising against the earlier, well-emulated instruction set means that the difference between emulated and real hardware gives us the answer of how well AVX2 emulation performs.

We can also use ARM64 on ARM, and AVX2 on x64, as a handwavy comparison for if you need ARM: an indication if emulation provides 'good enough' performance or if there's real value in compiling for ARM.

Thus:

• Using SSE2-4.x as a baseline for performance on both ARM and x64 (ie, scaled this to 1), what is the relative performance of AVX2 when emulated on ARM vs running on x64, and thus what overhead does ARM emulation of AVX2 provide compared to native?
• Using two kinda similar-gen machines, and hand-waving that it's nothing more accurate than that, how well does ARM-native vs x64-emulated vs x64-native perform? Do you need to compile for ARM, or can you get away with letting your apps run under Windows emulation?

Details

Performance tests instruct LLVM to build targeting the specific instruction set; are heavily vectorised; and our AVX2 level includes FMA (fused multiply-add.) We use only 256-bit wide AVX2, not the 128-bit wide instructions. Specifics are:

• Normalised to 1.0: CPU x86-64-v2 (referred to as 'SSE2-4.x' above, because those are the primary instructions math uses), feature set: +cx16,+popcnt,+sahf,+sse,+sse2,+sse3,+ssse3,+sse4.1,+sse4.2
• AVX2+FMA comparison: x86-64-v3, feature set: +cx16,+popcnt,+sahf,+sse,+sse2,+sse3,+ssse3,+sse4.1,+sse4.2,+avx,+avx2,+fma,+bmi,+bmi2,+f16c,+lzcnt,+movbe,+xsave
• ARM64: 'generic' ARM64 CPU, no specific feature set

Each math operation is run on a randomly initialised array of 64-bit doubles as input, in a loop (ie intended to be vectorised), 10 million times. The output is retained and 'used' in order to prevent the loop being optimised away. In IR, we verified the loop exists, is vectorised, and appears to look as expected. Numbers reported are typical timing runs, with no observable difference in cold vs warm runs. Timing is of course only around the tight loop itself, not the prolog or epilog setting the data up or 'using' the results.

All the 21 results are then scaled as a ratio vs baseline instruction set, x64 v2, and the geometric mean calculated to give a single representative number. This means that we can tell how much faster AVX2-level code is vs SSE2-4.x level, both on actual Intel hardware, and under ARM emulation.

Test machines

x64: Tiger Lake i7 (2.80 GHz), mobile-class CPU, circa 2021, on Windows 11 Pro 25H2.

ARM: Apple M2, circa 2022, macOS Tahoe 26.1 with the ARM version of the same version of Windows 11 Pro (25H2), running on Parallels 26.

x86_64 AVX2 emulation on ARM: Results

The following chart scales x64 v2 to 1.0 (grey baseline) and x64 v3 i(ie AVX2+FMA) is relative to that (Intel in green, ARM emulation in blue), that relative number calculated as the geometric mean of the result ratios of x64 v3 vs v2 for 21 common math functions run on 64-bit doubles per the above detailed description.

Normalised to 1.0, larger is better (faster).

As expected, using AVX2 on native Intel is significantly faster: 2.7 times faster.

But when the same code is run on ARM, the AVX2 implementations are notably slower than SSE2-4.x. They are almost exactly 2/3 as performant as emulating the older instruction set.

This means if your app uses x64 v3 with AVX2, and runs on emulated ARM on Windows, following this data, it will run slower than if you restrict it to the x64 v2 compilation level.

Why?

At the time I wrote the HN comment that started this, I had noticed that we didn't see faster performance using the AVX2 versions of our math function on ARM; what I had not yet measured was such a significant slowness.

Some possible reasons are:

• ARM has 128-bit wide NEON operations. AVX2 is using 256-bit wide operations (our code is not using 128-bit widths). This means the emulation code has to handle running two halves; it would be very close to impossible to make that equal performance.
  This is in my estimation the most likely single reason.
• The Prism AVX2 emulation code is new, compared to that emulating older instruction sets, and may not yet be fully optimized.
• It may optimise for heavily for 32-bit singles, not 64-bit doubles. Our math library focuses on double-precision.
• The ARM emulation documentation notes, 'Prism is optimized and tuned specifically for Qualcomm Snapdragon processors. Some performance features within Prism require hardware features only available in the Snapdragon X series...'
  These tests were on an Apple M2. While I'm sure Microsoft wants to support, or even prioritise, non-Apple hardware, in my view, Windows on Mac (via Parallels) is worth them supporting. But perhaps they don't support it well, yet.
• The emulation code may look for specific patterns that our code does not meet: perhaps, and this is entirely speculation, known (eg) VC++ Intel output, such as common RTL methods, may map to specific ARM64 patterns in the emulator. We are using LLVM, and (probably) rarer math implementations, therefore, less common sequences of operations.
  I cannot speak to how the emulator is implemented, and if this is even likely. It's a guess.
• Our x64 v3 performance seems, at this stage of testing, to be faster than Visual C++'s. (By a significant factor: in this chart, where our AVX2 code at our maximum FP precision came in at 2.7x the baseline, a VC++ 2022 version of the same benchmark compiled in x64 release mode, default FP accuracy, no further changes to default settings came in at 1.3x running on native Intel hardware. Yes, that is a 2x difference, and we attribute this to the VC runtime likely lacking AVX2-optimised math routines; their SSE2 math is slightly faster than ours, gosh dangnum darn it.)
  Therefore, for AVX2, using our compiler may be unfair compared to using other tools.

Meaning in practice

It is rare to have tight loops of operations: data processing, scientific and engineering software, etc., are the most likely. Even games may push much to the GPU. Therefore, the impact you see on your AVX2 app is unlikely to represent your app running at 2/3 the speed of your AVX2-4.x app. Only parts of it will.

If you have apps that do real number-crunching, whether that's native or something like Python, you should have the ARM version installed. (You likely have the ARM64 Python wheels installed anyway. But check.)

Although this checked floating point math, it is likely that it also applies to integer instruction set emulation too.

Therefore, it's likely worth treating Windows' ARM emulation of AVX2-level support as for support and compatibility, not for equal performance. To get performance, you'll need to compile as ARM.

If performance is key: Yes, it is absolutely key to build your app as ARM, not to rely on Windows ARM emulation.

This weeks Elememts build brings three new and exciting language features to the Oxygene language – and they all center around a single new keyword: field.

Field-Backed Properties

Things started off by bringing one of the new C# 14 features to Oxygene: Field-backed Properties.

Field-backed properties solve the conundrum where, as soon as you want a property to do anything more complex than just store and retrieve a value straight-up, you need to manually declare a field to store its value in by hand. With the new syntax, you can let the compiler handle that part for you, but still provide custom getter or setter code. And you can use the new field keyword (same in C# and Oxygene) to access the "backing field" from inside that code.

In C#:

private string _msg;
public string Message
{
    get { return _msg; }
    set 
    { 
        _msg = value ?? throw new ArgumentNullException(nameof(value)); 
    }
}

Now simply becomes

public string Message
{
    get;
    set 
    {
        field = value ?? throw new ArgumentNullException(nameof(value));
    }
}

No manual getter code; no private field declaration, no msg cluttering up the class's scope. And, most importantly, no chance to accidentally access _msg directly from other pasts of the class.

The same concept applies to Oxygene:

property Message: String write begin
  field := coalesce(value, raise new ArgumentException(nameOf(value));
end;

Any property that uses the field keyword in its read or write code becomes a field-backed property.

Also, any field-backed property will be read/write, and get its default read or write Implementation implied, if not specified, like in the example above. Why can we assume that's the intention? Because a read-only or write-only field-backed property would be pointless – who else would read (or write) its value, otherwise?

Field-backed Properties for Oxygene are documented in full, here.

Fields

Now that we have a field keyword in Oxygene anyways, this opened up the door for additional opportunities.

I have long been a proponent of proper naming, because the way we call things shapes the way we think about them. It's one of the takeaways I got from the excellent book Object Thinking, and one of the reasons why – as far back as version 1.0, before it was even called Oxygene – I pushed for the introduction of the method keyword to the language. Because Classes do not provide functions and procedures (and there are additional arguments on why Pascal's terminology re: functions and procedures is bad – but that is for another day), they provide methods. So it feels only right to use the method keyword to declare them.

Another thing classes (and records) contain is fields. In fact, a class without fields is not much of a class. Even though fields are (usually) variable, as in mutable, they are not variables! Yet, what (optional, alas) keyword did we use to declare fields? var.

No more! As of today, the field keyword can be used inside a class or record declaration to declare one or more fields, replacing var as the preferred and suggested option.

Of course, var will continue to work, for backwards compatibility; just as function and procedure are still there to this day, if you prefer. But field is the way to go.

Field type members in Oxygene are documented in full, here.

Local Fields

But we did not stop there.

The third and probably coolest application of the field keyword is inside code, i.e. in the body of your methods.

Of course, the var keyword sticks around for declaring variables inside your code, whether in a var section at the top of your method, or – the preferred Oxygene way since 2004 – inline with the var statement.

This is not changing. But we've introduced a new field statement that follows the same semantics, but will declare a field on class-level – but scoped to be accessible only in the current method or scope. The field will be initialized the first time the line declaring it is hit, and after that, its value will persist across all future calls to the same method (on the same instance).

Essentially, a local field is like declaring a regular private (all fields should be private) field, but limiting access to it to a single method or scope within a method.

• Local fields can be instance (the default) or static for the class when using class field or the static modifier. (same as for regular, global fields).
• Local fields in a static method or a static class will, of course, always be static.
• Local fields in an instance constructor need to be static (because what would be the point, otherwise) and are not supported in a (static) class constructor.

For example, this Log method keeps internal track of indentation level, based on what strings it got sent to writeLn:

    method Log(aMessage: String);
    begin
      field fIndent := 0;
      if aMessage.StartsWith("<-") then
        dec(fIndent, 2);
      writeLn("".PadEnd(fIndent, ' ')+aMessage);
      if aMessage.StartsWith("->") then
        inc(fIndent, 2);
    end;

Local Fields for Oxygene are documented in full, here.

Get All Your Fields Now!

All of these (and field-backed properties in RemObjects C#, of course) are available in Elements .3057, out on the Preview channel today. We expect next week's .3059 to bring them ot the Stable channel and the free trial.

Read more about Elements here. New stuff is being added to Elements every week.

If you're a Delphi developer, you might not be used to thinking of Object Pascal as a language that produces very fast code. Not in the way people talk about C++ or Rust, anyway; those languages are famous for performance.

We think that should change. And we've done something about it.

Depending on your platform and what your code does, recompiling your Object Pascal with Oxygene instead of dcc32/dcc64 could now give you 4x to 11x faster math performance.

In our benchmarks, we're on par with Visual C++, and at the AVX2 level, faster than Visual C++ – yes, in Pascal. Let me explain what that means and how it works.

How we got here

Back in November we upgraded Elements' LLVM backend and, while we were there, got curious about our math performance. Island, our LLVM native code compiler backend, uses the IslandRTL for many functions including math. We don't reuse the system C RTL, because it can have varying implementations on every platform. We provide our own. Our math functions had correct implementations, of course, but we realised modern instruction sets offered an opportunity we hadn't yet taken.

It also became apparent that LLVM wasn’t being fully leveraged. While standard optimisation passes were in place, the possibility of going further was worth exploring.

So we set about investigating. What do other toolchains do? What does Visual C++ do? What does Rust do? What do other LLVM-based toolchains do, which are best practices we can also make use of?

What Is Island/Delphi?

Elements is our compiler with six language frontends: Oxygene (Object Pascal), C#, Swift, Go, Java, and VB. One compiler, multiple input languages, all of which can interoperate seamlessly; our own IDE is written using multiple languages in the same codebase, inheriting from and calling methods written in different languages with no bridging layer. It's a bit like Delphi & C++Builder, but six languages not two, and fully multidirectional across any language to any other.

Elements can target multiple platforms: .NET, JVM, WebAssembly, and native CPUs. The native CPU target is what we call 'Island', and it uses LLVM, the same compiler infrastructure as behind Clang, Rust, and Swift.

Island/Delphi is a mode where you can import a Delphi project and compile it with Oxygene, linking to Delphi packages. This includes using the VCL; the Water IDE imports the VCL and other standard Delphi packages, though third-party components need to be imported manually (a straightforward File > Import step, which you can also do in the Fire IDE on macOS, or within Visual Studio.)

Island/Delphi isn't at 100% Delphi compatibility yet: think of it as a v0.9. But we think it's amazing: for many projects you can import and rebuild. Your Object Pascal still works, your VCL forms still work; the difference is what happens at compile time, because you get the benefits of a modern LLVM-based toolchain, including a wide variety of modern language features that Object Pascal developers have asked for.

What We Improved Lately

Two things that work together:

1. A fast, vectorised math library

We looked at what other toolchains did to get faster math than the default system libraries. Rust developers who want vectorised math can use SLEEF, so we integrated it.

SLEEF is an open-source math library designed for SIMD operations, providing vectorised implementations of sin, cos, exp, log, and the rest.

What does vectorised mean? Rather than processing one value per CPU instruction, a vectorised operation processes multiple values at once. Modern CPUs have wide SIMD registers: 128-bit, or 256-bit with AVX2. A 256-bit register holds four 64-bit doubles, so a single instruction can process four values at once. This is how you get significant speedups on numerical code.

2. CPU target selection

You can now tell the compiler which CPU level to target:

• Win32: SSE2 (always)
• Win64: x86-64-v1 through v4 (default to v2; and we recommend v3 if your users have ~2013+ hardware)
• ARM64: Native Windows ARM compilation, which Delphi doesn't support yet

When you target a higher instruction set level, the math library uses more capable implementations. AVX2 for v3, for example, processes 256 bits of data per instruction instead of 128.

You can read more details on our general Elements blog post, since this benefits all six Elements languages.

The Performance Difference

We benchmarked 21 common math functions (sin, cos, exp, pow, log, sqrt, and so on) running each 10 million times on 64-bit doubles. Here's what we found comparing to Delphi 13.

Hardware: Intel Tiger Lake i7 (2.80 GHz), Windows 11 Pro 25H2. ARM tests on Apple M2 running Windows 11 Pro 25H2 ARM via Parallels.

Methodology: Each function runs in a tight, vectorizable loop (if the compiler takes advantage, which ours does.) Each processes an array of 10 million elements with random double values. Only the loop running the math operations is timed; the initialisation plus use of the results (to avoid the loop and results being optimized away) are outside the timing. Read more about the methodology here.

The reference compiler is normalized to 1.0. All reported results are expressed as multipliers relative to this baseline (for example, '4x faster' means four times the performance of the normalized compiler).

Win32

Oxygene Win32 (SSE2 default): 4.2x faster than Delphi Win32

Win64

• Oxygene Win64 v2 (default): 2.3x faster than Delphi Win64
• Oxygene Win64 v3 (AVX2): 5.5x faster than Delphi Win64
• Visual C++ Win64 AVX2: 2.7x faster than Delphi Win64

At our default settings we're roughly on par with Visual C++. With AVX2 targeting x86-64-v3, Oxygene is noticeably faster than VC++ also targeting AVX2.

Windows ARM

Delphi doesn't compile for Windows ARM, yet. If you have a Delphi Win32 or Win64 app running on Windows ARM, it's using Microsoft's Prism emulator to translate x86 instructions on the fly.

Oxygene ARM64 native: 11x faster than Delphi Win32 under emulation

This is not only the difference in using a highly optimising compiler, but it is also the difference between running translated code and running native ARM code.

Beyond Performance

Performance is what this post is about, but it's not the only reason to consider Oxygene.

Oxygene brings modern language features to Object Pascal: tuples, async/await, nullable types, soft interfaces, and more. You can use C# alongside Pascal in the same project. You can target platforms Delphi doesn't support: Windows ARM64, WebAssembly, Linux ARM, tvOS or watchOS...

If you've been looking for a way to modernise your Pascal development, a toolchain you can invest in that keeps up with current hardware and language design, Elements is worth evaluating.

The Practical Side

These are best-case numbers, i.e. tight loops of floating-point operations. Your real application probably doesn't consist entirely of sin() calls. But if you have code that does data processing, scientific calculations, signal processing, or anything else numerically intensive, you'll see real improvements.

The difference between "this calculation takes 10 seconds" and "this calculation takes 2 seconds" is highly noticeable.

In addition, instruction set supports means this applies to all code. Not just math code. Your string processing, or anything else, will be built with the same optimizing compiler that uses fast instructions and heavy optimization – just like C++, Rust, or Swift.

Try It Yourself

If you're curious:

1. Download Elements (there's a 30-day free trial)
2. Import your Delphi project: File > Import (Water on Windows, Fire on macOS, plus VS); the very first time, it will also import the VCL etc packages for you. At 4 seconds each for over a hundred, possibly for multiple bitnesses, it takes a few minutes. After this once-off step they'll be available right away for every other Delphi project you import in future.
3. Build with Oxygene targeting Island/Delphi (your imported project will be configured for this already)
4. Compare

Your VCL code works, your Object Pascal works; the difference is what happens at compile time.

This – modern CPU support, fast code – is the kind of work we do in Elements. If you try it, I think you'll find what it shows.

In our view, this work strongly supports Delphi by providing what it does not have inbuilt, whether that's platforms, compiler behaviour like optimizations or fast math, or language features. A compiler is just a component of your development environment, and since its beginning thirty years ago, Delphi has been all about replacing inbuilt components with third party ones: doing so is intrinsic to Delphi development and a big part of the Delphi ecosystem. Our suggestion you use Elements to compile means we directly recommend and support using the VCL and other Embarcadero technologies.

We are grateful to Embarcadero for their support as a tech partner ❤️, and hope our value for the Delphi ecosystem really shines 🌟.

We recently upgraded Elements' LLVM backend and, while we were there, got curious about our math performance. We had our own implementations of sin, cos, exp, and the rest, which were correct, but modern instruction sets offered an opportunity we hadn't yet taken.

We looked at what other toolchains did to get better math performance than the system libm (libmath, ie, inbuilt C RTL.) Our toolchain does not use the system C runtime in general, so we don't delegate to it, even for math.

Among other things, when researching, we found that Rust developers who want vectorised math or to not rely on the system libm can use SLEEF. It's open source, accurate, fast, and supports multiple instruction set levels.

We prototyped it. Got some exciting numbers. We integrated it.

There are not many math libraries of this calibre. There are others: GPL-ed, or commercial, or Intel-only, or ARM-only. SLEEF is absolutely amazing.

The results were significant enough that we wanted to share what we did and why it works.

What We Changed

Two things, which complement each other:

1. A new math library

SLEEF provides vectorised implementations of common math functions (sin, cos, tan, exp, log, pow, sqrt, and so on.)

What does vectorised mean? Rather than processing one value per CPU instruction, a vectorised operation processes multiple values at once. Modern CPUs have wide SIMD registers: 128-bit, or 256-bit with AVX2. A 256-bit register holds four 64-bit doubles, so a single instruction can process four values at once. This is how you get significant speedups on numerical code.

Taking advantage of this in general requires an optimising compiler that uses newer instruction sets – see the next section ;)

Sleef supports both Intel and ARM, and has both scalar (ie normal one by one) and vector (several at a time) versions of math operations. Its scalar functions can dispatch, that is, check the CPU and call a different internal implementation at runtime depending on what your CPU supports.

Its vectorised methods do not: you need to call and link the right ones depending on the target CPU.

Rather than building the math library multiple times for a target (like x64 with multiple levels of instruction sets) instead we use LLVM's support for vectorised math libraries, plus instruction sets, so that a version of the library - IslandMath.lib - contains all the various variants, and at compile-time/link-time our compiler instructs which set to use. This requires really tight integration with LLVM, including:

• LLVM's target CPU, and CPU feature set (supported instructions LLVM is allowed to use)
• LLVM intrinsics (because an intrinsic for trunc, say, needs to be able to be converted to this method call – including taking the intrinsic and using it in vectorised form)
• and LLVM's inbuilt awareness of math libraries: large tables of operations, widths, instruction sets, and methods to link to.

Thus we have a chain. In reverse it is: LLVM (target CPU and feature set, intrinsic, math library support) ⬅️ Elements compiler (specifies target CPU, specifies microarchitecture) ⬅️ EBuild build system (handles projects, passes the compiler its settings, handles automatic references to the math library.) Quite a bit to implement.

For your apps, IslandMath is an implicit reference. Our build system, EBuild, links it automatically. It is visible in the IDE: you always see what is being referenced and linked to in the Water or Fire IDEs, even if it's automatically managed.

2. CPU target selection

You can now tell Elements which CPU level to target:

• 32-bit Windows: Pentium 4
• 64-bit Windows: Choose x86-64-v1 through v4 (corresponding roughly to ~2000, ~2008, ~2013, ~2017 eras)
• ARM64: We handle this internally. Apple Silicon gets M1-specific targeting; Windows/Linux ARM gets generic ARM64.

Our default is x86-64-v2 for 64-bit, and 32-bit uses SSE2: conservative choices that work on any reasonably modern hardware.

These features enhance each other. When you target x86-64-v2, our math library uses SSE2+SSE4.1 implementations. When you target x86-64-v3, it uses AVX2+FMA implementations, which means 256-bit wide operations instead of 128-bit. More data processed per instruction means faster execution.

We also tuned our LLVM passes for better vectorisation. By customising passes, as well as customising how passes worked, we were able to ensure more code patterns that could be vectorised actually were vectorised. We believe this is similar to how the Intel C/C++ compiler works, which was famous for performance and we understand – don't quote us – made a similar set of analyses. It certainly worked for us.

The Results

We benchmarked 21 math functions (the standard C RTL set: sin, cos, exp, log, pow, sqrt, etc.), each running 10 million iterations on arrays of 64-bit doubles. We compared Elements to Visual C++ 2022 and  Delphi 13, running on the same hardware.

Hardware: Intel Tiger Lake i7 (2.80 GHz), Windows 11 Pro 25H2. ARM tests on Apple M2 running Windows 11 Pro 25H2 ARM, via Parallels.

Methodology: Each function runs in a tight, vectorizable loop (if the compiler takes advantage, which ours does.) Each processes an array of 10 million elements with random double values. Only the loop running the math operations is timed; the initialisation plus use of the results (to avoid the loop and results being optimized away) are outside the timing. Where possible, i.e. for Elements, we looked at the IR to verify the code was behaving as we expected. We report the geometric mean of per-function speedups across each toolchain, which gives a single representative number that isn't skewed by outliers.

Win32

What we haven't added here is Visual C++'s SSE2 support (see below, roughly the same as the Win64 chart), where they are a shade faster than us, gosh dangum darn it. ...but wait, Win64 is another story entirely. Oh boy:

Win64

Compared to Delphi Win64:

• Elements Win64 v2 (default): 2.3x faster
• Elements Win64 v3 (AVX2): 5.5x faster
• Visual C++ Win64 AVX2: 2.7x faster

At our default settings (x86-64-v2), we're roughly on par with Visual C++: as noted, their SSE2 support is a shade faster than ours. (Compare the Elements x86-64-v2 bar on the chart above with the VC++ SSE2 bar: 2.27x vs 2.6x.) But if you can target x86-64-v3 (most CPUs from ~2013 onwards) and compare against Visual C++ using AVX2, Elements is significantly faster than Visual C++.

Wow!

ARM64

Not all toolchains compile for ARM, and their apps run under emulation. This lets us see the performance difference from native ARM combined with our optimizations and math library:

Delphi doesn't compile for Windows ARM yet. If you're running a Delphi Win32 app on Windows ARM under emulation:

• Elements ARM64 native: 11x faster than Delphi Win32 under emulation

Why Is This Faster Than VC++?

We were curious about this too.

Our best explanation for Intel is that Visual C++'s runtime library likely doesn't have AVX2-optimised math routines, or at least not as aggressively vectorised as SLEEF. VC++'s SSE2 math is actually slightly faster than ours on a few specific functions (sqrt, ceiling, floor), but SLEEF's vectorised implementations pull ahead on the trigonometric and hyperbolic functions, and that's where the overall result (the geometric mean) wins.

This applies to all six Elements languages. We wrote the benchmarks in Oxygene (Object Pascal), but that's the compiler frontend layer: the backend where this takes effect is the same for C#, Swift, Go, Java, and VB.

Practical Impact

These benchmarks are tight loops of floating-point math, ie the best case for this kind of optimisation. Your real-world app probably doesn't consist entirely of math. Yet, your real-world app will have many parts that benefit from the optimizations we offer outside of math.

That said, if you have code that does real number-crunching (data processing, simulations, engineering calculations, audio/video processing) you'll see meaningful improvements. The difference between "my app processes this in 10 seconds" and "my app processes this in 2 seconds" matters.

Try It

This – performance, modern features and settings, deep-in-LLVM engineering – is the kind of work we do on Elements. If you try it, I think you'll find it shows.

This week's build of Elements 12, build .3047, introduces a major new feature for the Oxygene language: Raw Strings. Raw strings are a new way of declaring string literals that make it easier to define more complex strings without worrying about escaping things such as quotes or curly braces.

Raw strings can come in two forms that behave similarly in most ways: single-line raw strings and multi-line raw strings. Any raw string literal starts with one or more hash symbols (#) followed by one or more double quote symbols ("), and all raw strings support interpolation with curly braces ({).

Single-line Raw Strings

A single-line raw string starts with the opening sequence (#" or a variation thereof), is followed by one or more non-quote characters, and then terminated by the same number of quotes that started it. Inside the literal, quote (and hash) characters can be used at will, as long as they are fewer than the quotes in the opening sequence, and they are not the first or last character:

var x := #""He said, "Hodwy!"."";

In the above example, the opening sequence has two quote marks after the hash: #"". This means the string will continue until another set of two quotes is encountered. Using single quotes inside the literal, like around the "Howdy", is fine, and they do not need to be escaped.

This works for any (reasonable) number of quotes:

var y := #"""""Want four quotes? why not!"""". It's fine!""""";

Note: For ambiguity reasons, a single-line raw string cannot be empty, as it would be impossible to tell whether it's just starting, or done. But then, an empty raw string is pointless – just drop the # and make it a regular string literal ;).

A single-line raw string must be terminated on the same line that started it (duh! 🙃).

Multi-line Raw Strings

A multi-line raw string starts with the same opening sequence (#" or a variation thereof), immediately followed by a linebreak. No non-whitespace characters may follow on the same line, not even comments (comments inside a string aren't comments, anyways ;).

The actual content of the string literal will start on the next line, and may continue across as many lines as needed to express the string you need.

The closing sequence – the same number of quites that started it – must follow on its own new line, preceded by nothing but whitespace:

var z := #""
         As the water flows over the bridge
         As we walk on the floodland
         As we walk on the water
         We forget
         We forget
         Rain from heaven 
           - The Sisterhood, "Rain from Heaven"
         "";

As before, the number of quotes in the opening sequence determines how many quotes are needed to terminate the string (here, two, therefore, the individual quotes on the last line are accepted as part of the string).

Multi-line raw strings have one additional special behavior, and that is the trimming of leading whitespace. The compiler will look at the number of spaces (tabs count as two spaces) in front of the closing quotes ("";), and remove the same number of leading spaces from the beginning of every line in the string.

As a result, even though the string is indented in code to match its surrounding – loosely suggested by the length of the var z := – the lines of the lyrics will have no indentation in the final string, and the last line of attribution will have only two spaces of indent.

This means you no longer need to have your multi-line strings stick oddly to the left edge of your code, defying the indentation of its surrounding code.

Note: All lines of the string must be indented at least as much as the closing quotes. If a line "sticks out" to the left, the compiler will emit an error.

Also note that the string literal shown above does not include a leading or trailing line break. It starts with A and ends with ". Of course, empty lines can be added at the start or the end of the literal, to add additional linebreaks. The string literal will also not include any trailing whitespace on any line.

Interpolation in Raw Strings

All raw strings support interpolation, similar to the existing interpolated strings starting with $" that Oxygene has supported for a while.

Just like the number of starting quotes indicates how many quotes end the string, the number of hashes (#) indicates how many curly braces ({/}) are used for interpolation:

var a := #"It's {time} o'clock.";

In its simplest form, a single curly starts and ends interpolation, just as you're used to from classic interpolated strings. In fact (with a couple of small caveats noted below), you can probably change most of your interpolated strings over to raw strings, just by replacing the $ with a #.

What if you want literal curly braces in your string... literal? No problem, just use more than one # in the opening sequence, and you can have as many as one fewer consecutive curly braces in your string, anywhere. Need some inline Json, for example? easy:

var j := ##""
         { 
           "Title": "IT", 
           "Author": Stephen King",
           "Published": 1984
         }
         "";

Need more than one? Also no problem:

var k := ###""{{Hello in double curlies, {{{lName}}}}}"";

Here, the double curlies at the start are kept literally, but the triple curlies near the end will treat lName as interpolated code.

If a literal contains more consecutive curly braces than needed to start an interpolation, the additional curly braces are kept literally:

var l := ##"keep a curly here: {{{5+3}}}"; // "keep a curly here: {8}"

Note: as mentioned before, there are a couple of small behavioral differences between interpolated raw strings. These are especially important to keep in mind if you are changing your $" strings to #" for consistency:

In classic $" interpolated strings, two {{ would be used to "escape" the interpolation. Raw strings do not do escaping like that, so you'd want to use  ##" instead, to have single-curlies in your literal without the need to escape them:

var x := $"{{keep one curly}"
// equals:
var x := ##"{keep one curly}"

Also, classic $" interpolated strings (and non-interpolated strings with double quotes) may contain linebreaks at any point, and will preserve all leading whitespace. Raw strings, as outlined above, will not, and must start on a fresh line, if they are multi-line:

var x := $"this
 is fine";
// equals:
var x := #"
         this
          is fine
         ";

Editor Support

The code editor in Fire and Water has been updated to visually highlight (or rather, lowlight) the curly braces "swallowed" by the interpolation. Especially when you're surrounding interpolations with additional curlies, this is a helpful visual aide:

Also: Delphi Multi-line Strings

It's worth mentioning here that a short while ago we also added support for Delphi's new multi-line string syntax, for compatibility purposes. Delphi multi-line strings start with an odd number of three or more single quotes ('), and end with the same amount. Similar to Oxygene's (and C#'s) raw strings, they too require the content of the literal to start on a new line, have the closing sequence on a new line, and will remove any leading whitespace. They do not support interpolating.

var d := '''
   Delphi's multi-line
   string syntax 
   is supported too
   ''';

Get Elements .3047 Now.

Elements build .3047 – with the new Raw Strings on Oxygene and much more is available on the Stable channel now, as free update for all customers, and as free trial download for new users.

Enjoy!

A few months ago, we previewed an AI coding assistant for Delphi called CodeBot at Embarcadero's AI Code Camp. In October, we gave a preview of an early alpha to the attendees at EKON. On January 13th Embarcadero and RemObjects will have a special webinar on CodeBot, including info about the beta!

Join live on Youtube here – no registration required!
Tuesday 13th January, 12 midday US Central, 6PM UTC.

And we have a teaser for it:

We're really looking forward to this webinar – don't forget to sign up for CodeBot updates at the bottom of this page!

From all of us here at RemObjects Software, we would like to wish you Merry Christmas, Happy Holidays, and a Happy New Year!

2025 has been an incredible year for the company and for our products. We have expanded our team, shipped countless updates to all products with many exciting new features, as well as launched the first brand new product in a few years. And our Oxygene language has seen its twenty-year anniversary this past year!

We're still just getting started, and we can't wait to share with you what's coming next!

See you in 2026.

Take care
–marc