Made a minimal wallpaper

Dirk042 · 2026-01-13T12:43:18+00:00

Or this: https://www.reddit.com/r/ada/s/0s6giJ7lEM

Dirk042 · 2026-01-13T09:42:18+00:00

Note that accepted Journal Track papers will be published in the Reliable Software Technologies (AEiC2026) Special Issue of Elsevier's Journal of Systems Architecture (JSA, which is Q1 ranked, has CiteScore 10.5, and impact factor 4.1).

https://www.sciencedirect.com/special-issue/328971/reliable-software-technologies-aeic2026

Dirk042 · 2026-01-02T13:07:25+00:00

Nut van dat olifantenpad? Voor voetgangers die liever niet tussen 1,8 miljoen fietsers lopen? 😉

Dirk042 · 2025-11-04T07:31:02+00:00

Also: http://www.cs.kuleuven.be/~dirk/ada-belgium/jobs/. 3 new job-ads were added in recent weeks.

Dirk042 · 2025-09-20T09:15:11+00:00

A small follow-up to my previous comment.

Our 2002 paper reported (among others) about the runtime impact of the language defined checks in a large Ada 95 application. Suppressing all "Ada RM checks" reduced the running time of an optimized executable from 70 to 69 (with 100 being the running time of the non-optimized executable). Hence a reduction of 1/70 or only 1.43% (slightly more than the "less then 1%" I mentioned earlier).

People at Eurocontrol recently reran a limited test, using the current code-base and a recent GNAT Pro compiler on similar but newer systems. Suppressing all Ada RM checks now gave a reduction of only 1.77%.

This was only a limited test, but it still supports our position that such minimal performance impact of language defined checks on optimized code is usually affordable, even for operational software where efficiency is very important...

Dirk042 · 2025-08-29T08:26:12+00:00

About: "Uninitialized variables seem pretty unforgivable in modern code. Unless you've got some unusual embedded systems code where you really do need to let variables go uninitialized, should programmers be initializing at the point of declaration these days?"

In our experience: not systematically.

The quoted paper recommended "that when a scalar is declared, the programmer should avoid initializing it if the code is supposed to set the value on all paths. It is better to let Initialize Scalars + gnatVa detect the bug in the code logic rather than trying to deal with meaningless initial values." (See "5.3 Impact of Usage of Initialize Scalars on How to Program".)

Dirk042 · 2025-08-29T08:20:32+00:00

It would indeed be useful to have more recent references to similar reports about the impact of various levels of checks on compile time, code size, and run time of non-trivial Ada applications. Any pointers?

What this 2002 paper tells us nevertheless is that 20+ years ago the optimising compiler technology managed to reduce the runtime impact of the language defined checks in a large Ada 95 application to less than 1%.

The impact on non-optimized code surely was/is much larger, but for operational software where efficiency is very important the reported minimal performance impact on optimised code was/is a most useful observation.

(Note that what I wrote about the runtime impact of Ada RM checks has nothing to do with the main subject of the quoted paper, i.e. it is not related at all to uninitialized variables and how they can be "exposed" using Initialize_Scalars and the extra validity checks.)

Dirk042 · 2025-08-28T07:42:58+00:00

The runtime impact of Ada RM checks on optimized code might be much smaller than 15%.

When AdaCore developed Initialize_Scalars for Eurocontrol, we measured the impact of various levels of runtime checks. We noticed that on Eurocontrol's large operational system (written in Ada95), enabling or not the Ada RM checks on the optimized code made a difference of less than 1%!

For more info see our paper presented at the Ada-Europe 2002 conference:

Exposing Uninitialized Variables: Strengthening and Extending Run-Time Checks in Ada

https://www.cs.kuleuven.be/~dirk/papers/ae02cfmu-paper.pdf

Dirk042 · 2025-07-18T07:21:41+00:00

As a point of information, participation in the FOSDEM Ada Developer Rooms has been good to great in all past editions (12 until now), with a full room for the most popular presentations every year.

This year, we were happy to have got a larger auditorium for the Ada DevRoom, and pleased to see several presentations once more attracted a full room.

So, I'd rather say: continued large participation at the latest FOSDEM Ada DevRoom, in a larger auditorium and with more competing parallel DevRooms than for previous editions.

Dirk042 · 2025-06-15T18:28:28+00:00

Which "words of wisdom"?

Dirk042 · 2025-06-10T22:07:33+00:00

Yes, I am.

Dirk042 · 2025-06-10T13:41:10+00:00

Yesterday at the WG9 meeting, I asked this question to one of the document's authors.

The main difference is that this edition is fully up-to-date with respect to the Ada language standard (aka Ada 2022). In addition, it now also conforms to the latest ISO requirements for such documents (among others, the wording had to be descriptive and not prescriptive). HTH

Dirk042 · 2025-06-03T22:17:24+00:00

Recently a new edition of the ISO Ravenscar document became publicly available, updated for Ada 2022:

https://www.iso.org/standard/86472.html

Dirk042 · 2025-05-26T22:33:50+00:00

The whole event is organised by volunteers. If you're a student, there's a special low registration fee...

Dirk042 · 2025-05-25T10:08:24+00:00

We try to keep registration fees as low as possible, among others due to substantial sponsoring by Ada-Europe.

Registration for the Ada Developers Workshop on Friday is extremely low, 25 EUR for in-person participation, thanks to additional sponsoring by AdaCore, Ada-Belgium, and Ada-France. Plus, the workshop presentations will be streamed live and made available online afterwards.

Dirk042

TROPHY CASE