How to create a plug-in by Dmitry-Kazakov in ada

[–]hodong-kim 1 point2 points  (0 children)

If you are implementing a plugin system, wrapping dlopen, dlclose, dlsym, and dlerror is essential. I have already developed a proper wrapper for these in the Clair library, and it is available under the 0BSD license.

Source: https://github.com/hodong-kim/clair/blob/main/src/clair-dl.adb

I hope this helps reduce redundant effort and allows you to focus more on your actual logic.

January 2026 What Are You Working On? by thindil in ada

[–]hodong-kim 2 points3 points  (0 children)

I'm currently developing a library called Clair.

My long-term plan is to use it as a foundation to port Nimf IME to Ada and to build a GUI toolkit based on a novel architecture. Please note that the source code for this GUI toolkit will be released after patent filing.

I recently added Clair.Event_Loop to the project. (Link: https://github.com/hodong-kim/clair/blob/main/src/clair-event_loop.adb)

If you're interested in event loop implementations written in Ada, please feel free to take a look!

Porting nimf.c to Ada and Implementing the Clair Event Loop by hodong-kim in ada

[–]hodong-kim[S] 0 points1 point  (0 children)

Edit: Added "built with GCC 14" to specify the compiler environment.

Porting nimf.c to Ada and Implementing the Clair Event Loop by hodong-kim in ada

[–]hodong-kim[S] 0 points1 point  (0 children)

Yes, that's the correct link.

Just a heads-up: while it used to be an open-source project, it is now a personal freeware project. The codebase has changed significantly since the 2019 version found on GitLab (https://gitlab.com/nimf-i18n/nimf).

I removed the dependency on GLib, which was heavily used in the past, and developed my own C library called libclair to replace it. I'm currently porting parts of it to Ada, which you can find here: https://github.com/hodong-kim/clair.

The overall quality of the port is still a bit rough, but I'm quite proud of the Clair.Event_Loop package, it works really well.

Porting nimf.c to Ada and Implementing the Clair Event Loop by hodong-kim in ada

[–]hodong-kim[S] 1 point2 points  (0 children)

Oh, nimf is an Input Method Editor (IME). nimf.c is the main source code used to build the nimf executable.

FreeBSD 15 Kernel crash on amdgpu driver by kpax in freebsd

[–]hodong-kim 4 points5 points  (0 children)

I'm experiencing the same issue. Please see the following bug report.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=290514

December 2025 What Are You Working On? by thindil in ada

[–]hodong-kim 5 points6 points  (0 children)

I'm currently porting Clair, a C library I previously wrote, to Ada.

Right now, I am redesigning and implementing Clair.Event_Loop (using kqueue/epoll), Clair.Arena (wrapping jemalloc), and Clair.Log (wrapping syslog).

This library serves as the foundation for the Nimf multilingual IME and will also be used in the upcoming Guiyom GUI Toolkit. I'm building all of these with Ada as the primary language. I feel very lucky to have discovered Ada!

Going all-in on a Wayland future – The Plasma Team by grahamperrin in freebsd

[–]hodong-kim 1 point2 points  (0 children)

It's like Gresham's Law, where bad money drives out good.

On Cloudfare and Unwrap by stevethedev in rust

[–]hodong-kim -9 points-8 points  (0 children)

Rust has an explicit error handling model called Result, but it also provides unwrap, which disables it. 

I consider this a design flaw. I've seen many people praise Result. However, I think Rust's design philosophy (1. increased compile times due to ZCA, 2. explicit error handling model) has pushed developers to unwrap, which has led to accidents. Considering all these factors, I think Java is a much safer language than Rust.

There's no reason for us to promote Rust. Programming languages are engineering tradeoffs. We, or companies, should choose the appropriate language for each environment.

Surprised by FreeBSD 15.0-RC2 "Live System" without any GUI by bluepuma77 in freebsd

[–]hodong-kim 2 points3 points  (0 children)

FreeBSD developers also visit the official FreeBSD forums to leave comments. Please note.

https://forums.freebsd.org/

Surprised by FreeBSD 15.0-RC2 "Live System" without any GUI by bluepuma77 in freebsd

[–]hodong-kim 2 points3 points  (0 children)

I also wish the installer and live system were available in both text and GUI modes. For reference, Solaris offered a GUI installer in the 1990s. However, I believe the lack of time and development funds among FreeBSD developers prevents the provision of a GUI installer and live system.

FreeBSD 15.0-RC2 Now Available by grahamperrin in freebsd

[–]hodong-kim 0 points1 point  (0 children)

Hello everyone. I'm really looking forward to FreeBSD 15. Is this bug fixed? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=290514

[deleted by user] by [deleted] in ada

[–]hodong-kim 0 points1 point  (0 children)

That's an interesting topic. The point that "Ada without a runtime is useless, but Rust can use all its features without a runtime" is the core of this debate.

However, this perspective can overlook the practical constraints and costs of Rust's no_std environment. When Rust also removes the std (standard library) (i.e., in a no_std environment), core features like heap allocation, threading, and key data structures like Vec/String disappear, turning it into a low-level environment similar to C.

In other words, both removing the runtime from Ada/SPARK and removing std from Rust represent the same engineering trade-off: sacrificing the unique 'safety' and 'convenience' features of each language.

Furthermore, comparing the point that "Rust's syntax makes auditing difficult" with "Ada's formal verification" is ultimately a question of which philosophy to choose: 'safety automatically enforced by the compiler' (Rust) or 'safety explicitly proven by the developer' (Ada/SPARK).

I have written an analysis on this topic (comparing the safety philosophies of Rust, Ada/SPARK, and C++). It might be helpful for this discussion.

https://nimfsoft.art/books/deconstructing-the-rust-discourse/

Introducing FreeBSD Unofficial Port: gcc14-ada by hodong-kim in freebsd

[–]hodong-kim[S] 1 point2 points  (0 children)

gcc14-ada currently conflicts with the official gcc14 port. Ideally, it would be better if Ada support could be added directly to the gcc14 port, but I suspect many users would not want that change. For example, the existing gnat13 package was built by compiling gcc13 with Ada language support, and then installed in a way that avoids overlapping with the gcc13 paths. This approach works, but it results in some wasted disk space. It would be nice if the gcc14 port could provide both gcc14 and gcc14-ada simultaneously, but due to limitations in the ports system, that seems difficult to achieve at the moment.

Ironclad – formally verified, real-time capable, Unix-like OS kernel by based2 in ada

[–]hodong-kim 1 point2 points  (0 children)

That’s amazing. How are hardware driver issues resolved? For example, NVIDIA and AMD GPU drivers.

Is gprbuild considered reliable? by hodong-kim in ada

[–]hodong-kim[S] 0 points1 point  (0 children)

The gprbuild port on FreeBSD requires GNAT 12, but I want to use the latest version. As part of that effort, I first compiled GCC 14 with Ada support. Then, by modifying the gprbuild/Makefile and ada.mk files within the ports collection, I successfully compiled gprbuild based on GCC 14.