ziotom78
It is being used by many projects for this purpose: GNU Cash, Lilypond, GNU Guix... I don't know about games, however.
Congratulations to the team, Chicken Scheme is a little gem!
Do you have any trustable source for this?
However, it often makes conceptual errors that I can spot only because I have good knowledge of the topic I am discussing. For instance, in 3D Clifford algebras it repeatedly confuses exponential of bivectors and of pseudoscalars.
Good to know that ChatGPT 5.5 Pro can produce a publishable paper, but from what I have seen so far with Gemini, it seems to me that it is better to consider LLMs as very efficient students who can read papers and books in no time but still need a lot of mentoring.
However, when I checked who the author is, I found he is is Graeme Geldenhuys, the author of the fpGUI library [1]. He surely has a lot of experience with FreePascal and the Pascal language, and in these years he has proven to be a committed worker (fpGUI exists since 2010!). So, this project seems to start on good grounds!
I really hope it will gain traction, as I have often wondered myself why somebody would not create a “clean” Pascal compiler from scratch with no legacy cruft and good defaults (e.g., UTF-8 strings, inline variable declaration).
Do you have a Life Cicle Assessment source for this? This paper [1] quantifies the Energy Payback Time for a modern nuclear plant to be roughly 6 years (see Table 18), and EPT is a conservative metric because it accounts for the total embodied energy of construction (steel, concrete…). For a plant running for 60 years, this means that it will be significantly less than 10%, not 25%.
> solar would have made far fewer emissions
Again, do you have a source? Referring to this, it does not seem so [2]: 6 tonCO2/GWh for Nuclear vs 53 tonCO2/GWh for Solar.
> they are big up front money sinks, creating a sunk investment, diminishing the gamma of future options one might have wished to invest in, or take advantage of, something nobody talks about
True, nuclear has a big initial cost, but this is an incomplete metric. It ignores system integration costs, which grow non-linearly as solar penetration increases. Intermittency forces the grid to over-build capacity and storage, and significant investments are needed to fix it.
> They are perfect for government vanity projects, though, where a lot of money can be siphoned off to personal crypto gardens, repeatedly. Money laundering is likely the leitmotiv behind why you see them being built.
I agree, but this is true of any technology. In countries like Italy and Germany the Government provides >10 G€/year for renewables. It is quite likely that money laundering is happening in these cases as well, as corruption is generally a failure of the Government and auditing bodies, not a property of the energy source.
[1] https://www.sciencedirect.com/science/article/pii/S019689040...
> Flags are ephemeral – you have to share the command line or wrap it in a script. Scripts depend on environment, which can break portability. Filenames solve both: the program describes itself, requires zero setup, and any configuration can be shared by simply renaming the file.
[Emphasis added] Although I find a script that wraps the command and calls it more versatile, there might be some value in this idea for some very simple cases, like example #4.
To produce plots out of data files, Python and R are probably the best solutions.
It took just a couple of minutes to have a working example that fully supported C++ modules and `import std`:
set_languages("c++23")
add_rules("mode.debug", "mode.release")
target("mytest")
set_kind("static")
add_files("src/*.cpp")
add_files("src/*.cppm", {public = true})
set_policy("build.c++.modules", true)That four new CVEs (two high-severity!) were found in a mature and well-tested library like png reminds me how non-trivial and unforgiving software engineering can be.
Security flaws are often just waiting behind the corner: this should be humbling lesson for all of us.
- I use several symbols as Greek letters (α, β, γ…) and mathematical operators (×, −, ·, ∂…), and after much digging I found that the only way I could make keyd work with them was to choose a US keyboard layout. So, I had to write a configuration file for keyd to remap not only the special characters listed above, but every character of the Italian keyboard (è, é, ò, à, ù…). This extensive remapping required then an exception for Espanso to prevent `keyd` from intercepting its virtual keyboard output.
- However, this forced US-layout setup created a conflict with VirtualBox that I was unable to solve. When I installed Windows and selected the Italian layout inside the VM, the guest OS received the raw key codes corresponding to a US physical keyboard (due to the keyd remapping layer). Since the guest OS expected Italian key codes, all the standard Italian keys (like è, à, ò) stopped working correctly. Without keyd enabled, the standard Italian layout worked perfectly in the VM.
- The attempts to create application-specific exceptions (e.g., to disable keyd for the VM window) using tools like keyd-application-mapper did not function correctly in my KDE environment because of known issues in these tools.
- Finally, introducing new hardware like my Corsair keyboard added another layer of complexity, as its Linux driver (ckb-next) was incompatible with the active keyd remapping layer. This was the point when I decided to revert to X11.
I should definitely collect all these details and write a blog post about it…
- Italian layout for my keyboard with heavily-customized AltGr keys for mathematical notation (in X11 it's just a matter of having a Xmodmap file)
- Using Espanso for many common shortcuts like :date: (current YYYY-MM-DD date) and :pidigits:
- A reasonable way to run Windows in a VM while using an Italian layout for my keyboard
- The possibility to use automation scripts using something as close as possible to xdotool
- Sometimes I use my home keyboard, sometimes I use my work keyboard, and sometimes I use my laptop keyboard. I expect the system to work in the same way regardless of my input device
It's not that Wayland prevents one from doing all this stuff, but the available solutions were fragile and complicated and took me so long before figuring solutions that only worked partially... For instance, to make keyd work as expected, I was forced to set up my Italian keyboard as an English keyboard and then remap all the keys manually... And every time I plugged a new keyboard, I had to tell keyd to enable my customizations on it, because telling it to use the layout with any keyboard conflicted with VirtualBox.
I understand that X11 is too complicated to be maintained, but from an user's perspective, so far I am far more efficient in X11.
We used the same trick (git hash + git diff to monitor uncommitted changes) in a Python simulation framework we are developing for the JAXA/EU space mission "LiteBIRD." [1]
[1] https://iopscience.iop.org/article/10.1088/1475-7516/2025/11...
The email mentions that the last time they changed it was 5 years ago in GCC 11, and the link <https://gcc.gnu.org/projects/cxx-status.html#cxx17> indeed says
> C++17 mode is the default since GCC 11; it can be explicitly selected with the -std=c++17 command-line flag, or -std=gnu++17 to enable GNU extensions as well.
which does not imply a change in an obscure feature (bootstrapping) that would only affect a few users.