Lua 5.4.8 is here!

So it was, once again, time to build the NuGet package. To my surprise, building with Clang as tool chain unexpectedly failed:

C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\Llvm\lib\clang\19\include\stdarg.h(22): warning RC4067: unexpected characters following '#if/#elif' directive; newline expected [D:\a\nuget-lua\nuget-lua\compiler\compiler.vcxproj] 
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\Llvm\lib\clang\19\include\stdarg.h(22): warning RC4067: unexpected characters following '#if/#elif' directive; newline expected [D:\a\nuget-lua\nuget-lua\compiler\compiler.vcxproj] 
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\Llvm\lib\clang\19\include\stddef.h(22): warning RC4067: unexpected characters following '#if/#elif' directive; newline expected [D:\a\nuget-lua\nuget-lua\compiler\compiler.vcxproj] 
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\Llvm\lib\clang\19\include\stddef.h(22): warning RC4067: unexpected characters following '#if/#elif' directive; newline expected [D:\a\nuget-lua\nuget-lua\compiler\compiler.vcxproj] 
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\Llvm\lib\clang\19\include\stddef.h(51): warning RC4067: unexpected characters following '#if/#elif' directive; newline expected [D:\a\nuget-lua\nuget-lua\compiler\compiler.vcxproj] 
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\Llvm\lib\clang\19\include\stddef.h(51): warning RC4067: unexpected characters following '#if/#elif' directive; newline expected [D:\a\nuget-lua\nuget-lua\compiler\compiler.vcxproj] 

I searched online for the compiler errors and if there were recent changes to Clang or the visual studio integration or something. But I found nothing. I tried to build the previous version of Lua in my GitHub action, and that one failed as well.

And after some minutes, I finally noticed the important bit! Those are NOT c/cpp compiler errors! Those are RESOURCE COMPILER errors!

I build all binaries, i.e. the Lua compiler, the Lua interpreter, and the Lua dll version, with version information resourced built in. And the resource script for that includes the lua.h c-header to use the version information defined in that file. As it is a normal c-header as well, it, of course, includes further files, among them the stdarg.h and stddef.h triggering the bugs above.

I suspect there was some optimization introduced to those system headers and the Cpp compiler, which is not reflected in the resource compiler. And I don’t blame anyone for that, as the resource compiler is something exotic anyway, and one cannot really expect it to be fully compatible with cpp.

The versioninfo resource script for those projects is generated anyway. So, I fixed this problem by no longer including lua.h in the version info header, but by duplicating all required defines. Just in case you (or my forgetful future self 😉) run into similar issues in other projects as well.

And with this, also the new NuGet package of Lua is now available.

Towards end of last year, I finally bought myself a 3d printer. With the BambuLab products I finally felt that the home-3d-printing technology had matured enough so that I would not have to fiddle with settings or stuff and would not need to spend time and thought on the process of 3d printing but could focus on the objects I want to print.

And here we are, the first two 3d objects I created and gave back to the 3d printing community: small, hinged boxes.

This is only the start of my journey. I have ideas for lot more stuff which can now become physical reality.

WordpressI have always written my blog here in two languages, in German and English. Back in the day, it used to be my own web code. Then at some point I switched to WordPress. And the plugins for multilingual posts, etc., have always been kind of … difficult.

And now my previous plugin for the multilingual blog has completely stopped working; probably due to a WP update or PHP update. Whatever. Doesn’t matter. So, let’s try out a another new plugin. And, this now manages different languages by having each post in exactly one language, and the same posts in different languages are “only” linked. Actually quite a nice concept.

But it also means that my previous posts all, really all, have to be revised, split, updated, etc. just like the website structure itself and all extra pages. And that will take time.

So, the content on my website will always look a bit broken until further notice. Sorry.


Update 2024-09-15: as I am fixing the blog articles, i.e. I am splitting the languages into separate articles, I notice links between the articles will most likely stay broken, especially in the english versions. Sorry, but I don’t care enough for the old stuff to fix that…

I came across that Nuget because I was writing WPF UI applications and I needed a folder picker. Someone in the internet suggests to use the WinForms dialogs. I sort of hate using two frameworks. And then another one brought up the Nuget WindowsAPICodePack.Shell with it’s class representation of the Windows Common Dialogs, including the capability of picking folders in the open dialog window.

So, I started using that. Then, at some point, a friend pointed out to me, that the Nuget package I was using did not look like an official Microsoft package, but a repackage someone did. That made me stop and think. I don’t assume any bad intent, but I found it very very strange. The official package vanished. And there is a huge load of packages which strange names:

I don’t like this. Even if there is no ill intent from any of the authors, I still don’t like this, as it reeks like fraught, phishing, and vulnerabilities. Sorry, but, no.

So, where is the official package? Seems to have disappeared, that’s why there are the repackages by community members. Why did it disappear? No idea. Maybe it got caught in a semi-automatic cleanup as it was orphaned. Someone suggestion it’s replaced by Microsoft.Windows.SDK.Contracts.

In the end, I replaced the code in my projects by either using the WinForms dialog, or by writing a very small p/invoke wrapper class calling the Win32 API directly. If you are interested, have a look:

https://github.com/sgrottel/open-here/commit/9de68198e35f0f6dec9386372cc71bada54c2f5b

The moral of the story is, a Nuget package is only as good as the people maintaining it. And, I mean people, not organizations. Because in the end, it’s whether or not individuals want to give their best.

GLM has been released in Version 1.0.0, and I updated the Nuget package accordingly.

With this, the Nuget package source code also moved from Bitbucket to Github.

I am not sure if updating Nuget packages is worth writing about. I’d rather say, it’s business as usual. But this instance here is special, as the GLM developer decided to go for 1.0.0. I want to especially congratulate on this occasion! It’s rather embarrassing how many projects seem to fear the “sonic barrier” of this step, finally switching from “I don’t know” to “This is sort of what I wanted to do and it is sort of done in its first version.” I believe, many more projects are mature enough and stable enough to go that step. But they don’t do it. I don’t know.

This is my first post in 2024, and amazingly, I managed to not post anything for seven and a half months. That might be a sad record. Well, it’s not that I did not do anything publicly available to the community in that time. It does show, however, that my priorities lay somewhere else than this blog. But I don’t want to give this here up just yet.

Anyhow, I don’t want to just write down a blown-up lazy list of what I did, e.g. repeating my Github journal, because, that would be just sad. If you are interested in what happened in my Tiny Tools, Everything Search Client, Checkouts Overview, OpenHere, LittleStarter, MyToDoBoard, updated Nuget Packages, SimpleLog, etc., I suggest you have a look at my Github profile directly. I guess, this is the non-blown-up list.

So, for today, I leave this little sad “I am still alive” message here.