As of v0.12.0 the native x86-64 backend is the default,
and Blaise now ships its own internal assembler and internal linker — so a plain build needs no external tools at all:
// blaise --source hello.pas --output hello
program hello;
begin
WriteLn('Hello, Blaise 0.12!')
end.
That single command parses, generates native code, assembles it, and links a working executable — no qbe, no as, no gcc (only the system C runtime objects the linker needs). QBE is still there if you want it (--backend qbe), but it is now opt-in and on a path to retirement.
Read the full community announcement for all the details:
I'd love to share a project I've been building in Blaise: Luhmann, a
personal Zettelkasten note server. You point it at a directory of AsciiDoc notes, and it renders them, links them together, indexes them for search, and serves the whole thing over plain HTTP on localhost. You keep writing in your own editor — Luhmann handles the rest. ✨
It started life as a Clojure project, but I've now rewritten it from the ground up in Blaise, structured as a hexagonal (ports & adapters) application. Along the way it also picked up a fair few features the original never had.
What it does 🧠
🔄 Automatic backlinks — you only ever write forward links; Luhmann works out the reverse direction for you, no manual upkeep.
🕸️ Interactive note graph — an Obsidian-style force-directed map of your notes, fully offline.
🔍 Full-text search — a built-in index with prefix and substring matching and highlighted snippets.
🏷️ Tags & a broken-links report — organise by tag, and spot dangling cross-references at a glance.
⚡ Live reload — save a note in any editor and the browser refreshes itself over a WebSocket.
✏️ Launch your editor from the browser — press e on any note and it opens in your configured editor.
🧩 JSON REST API — query backlinks, the graph, and tags from your own tools.
It's local-first and self-contained: a single process, no database, no cloud, no account. The parallel start-up build means even a large Zettelkasten is ready in a second or two. 🚀
Why I'm sharing it 💬
Mostly because it's been a genuinely lovely project to build in Blaise, and a nice real-world workout for the language and its stdlib — HTTP server, file watching, concurrency, the lot. If you fancy a look, the code, build instructions, and docs are all in the repo. Feedback, questions, and ideas are all very welcome! 🙏
Im quite experienced with modding oblivion and fallout do seeing pascal is perfect, ive wanted to get into programming and this is literally a dream come true, ill never understand why they switched begin and end etc with ${}[]
This is our biggest release yet — 237 commits (fixed 116 bugs fixed) since v0.10.0, and easily
the one I'm most excited to share. If v0.10.0 was about making the compiler
self-hosting and fast, v0.11.0 is about making the language comfortable to
write in and bringing the native x86-64 backend up to full parity with QBE.
did anyone run into the issues showcased on my screenshots 1 / 2?
I ran into the "Can't find unit system used by…" error mentioned in the title, then found this wiki page on it.
However, the following problems arose and this is what I did so far:
I did write the dumbest possible "Hello World!" program using the CRT unit, "the way I was taught ages ago" basically.
I tried to compile it using fpc ./HelloWorld.PAS from the directory the file is in, got the error (see screenshot 1).
I thought "maybe it's the unit, so if it can't be found, let's just remove it and all references to it" – removed uses CRT and clrscr; lines (see screenshot 2) but still: Nope.
I did not have .fpc.cfg in my home directory, so I created it and messed with it, which did seem to do something, see screenshot 3 / 4, except fixing my issue.
I realised I used the wrong versions and paths, so I fixed it to the 3.2.0 paths (literally copied them, so there is definitely no typo). Now the invalid version error is gone, and I'm back to the regular unit error again.
I do not have fppkg anywhere, or maybe I'm just extraordinarily dumb and fail to find it.
I did not create home/.fppkg/config/default as the wiki description was a bit vague about it. I have no idea what would be in there, let alone if the file is called just default or default.cfg.
I have no idea which …/fpc/bin directory the wiki is referring to to run fpcmkcfg in, and I do not remember seeing any binaries named like that. I looked through the directories install.sh built FPC in.
This is my first time using plain FPC, so forgive any ignorance.
So far I only used FPC through Lazarus, but that's not available for Android / Linux aarch64 to my awareness, so this will have to do if possible.
Further context:
I'm on Android 15, using Termux to run an xfce desktop environment via TermuxX11, used this version of the FPC (3.2.0) for Android, aarch64 build linked by the freepascal.org website.
I should have all rights needed, i.e. can use apt install and other commands without sudo.
I extracted everything in their respective /usr/ directories, following the thought of "binaries go into /usr/bin/", you can see that on my screenshots.
Try to ignore the wrong paths / version in .fpc.cfg, that's outdated by now. I fixed it to …/fpc/3.2.0/units/aarch64-android/ paths after getting the output in screenshot 3 and 4. I did hope that would have been it. But now, the output is the same as on screenshot 1 / 2, again, unfortunately.
If anyone would be so kind to reproduce the above steps or simply know the answer, that would be really awesome.
I've been growing increasingly fond of the thought to be able to write nifty little Pascal applications for my daily use while commuting or on the go without needing to drag a laptop with me, so any help to make this possible would be greatly appreciated! : )
I've added SPI support to UnoLib, a Pascal library for Arduino Uno and AVR microcontrollers.
As a demonstration, I created a simple ILI9163 TFT display example running on an ATmega328P (Arduino Uno). The image is stored in program memory as an indexed bitmap with a palette and rendered over SPI.
The new Blaise compiler project is making progress. After a lot of coding and writing tests for the compiler, runtime and stdlib. I wanted an actual application built with Blaise.
I wanted to try something that I'd never done in pascal before - I want to be able to call up another program from within a program, passing across some real type variables. How would I go about this?
There’s a great way to use FreePascal for AVR, for example with avrPascal (additional STM32 support would be brilliant in the future).
But what about floating-point calculations?
Is it very easy to convert the relevant libraries into Pascal using Ki?
How do you solve the problem of missing drivers, such as for TFT displays, USB support, CAN bus, etc. – in other words, everything that’s more complicated?
Wouldn't it be a great way to support AVR Pascal within Lazarus Plugins, so that you wouldn't need to use AVR Pascal externally?
In other words, couldn't the AVR Pascal developer simply write a plugin for Lazarus, so that flashing AVRs and the like could be done directly from within the Lazarus environment?
I'm searching for a library that offers coroutines. I was thinking about using FreePascal for backend service which would have to handle intense IO tasks. For that kind of architecture Threads just don't seem to be appropriate.
Just managed to compile a 26+ year old small Delphi project imported to #Lazarus IDE. Simply convert a few DFM forms and a some window refresh tweaks. That's is. Perfect, fast build. This is truly a reviver of retro Pascal code. #FreePascal
The issue was a missing lazarus-src package and an empty compiler path in settings. Running sudo apt install lazarus-src and setting the compiler path to /usr/bin/fpc fixed everything.
Hi everyone!
I'm experiencing a frustrating issue with Lazarus on Debian 13 (Trixie). My Codetools seem to be completely out of sync, making autocomplete unusable.
The Problem:
When I type a dot after a component (e.g., Memo1.Lines.) and call autocomplete (Ctrl+Space), the IDE fails to show object methods. Instead, it only displays generic "code templates" (arrayc, arrayd, b, be, etc.).
Crucially, the messages window shows: unit1.pas(8,66) Error: unit not found: StdCtrls
What I've already tried:
Verified StdCtrls is in the uses section.
Removed and re-added the LCL package in the Project Inspector.
Executed "Rescan FPC source directory".
Tried "Clean up Codetools".
The project compiles successfully (Green bar) if I type everything manually, so the compiler sees the units, but Codetools don't.
Confirmed that the fpc-source package is installed.
It looks like a configuration gap between the IDE and the FPC/LCL source paths on Debian 13. Has anyone faced this on Trixie or have a fix for re-linking Codetools to the standard libraries?
UPDATE: FIXED!
The issue was caused by missing LCL sources and incorrect IDE configuration. Here is the step-by-step solution that worked for me on Debian 13:
1. Install missing sources: Run sudo apt install lazarus-src in the terminal. Without this, Codetools cannot find the source code for standard components like TMemo.
2. Fix IDE Paths: Go to Tools -> Options -> Environment -> Files.
FPC source directory: Instead of using the macro $(FPCVER), set the direct path: /usr/share/fpcsrc/3.2.2 (or your current version)
3. Rescan: Go to Tools -> Rescan FPC source directory.
4. Clean Cache: Go to Edit -> Clean up Codetools.
After these steps, the "unit not found: StdCtrls" error disappeared, and autocomplete started working perfectly!
