CodeProject Latest postings for Hall Of Shame

CSS & Sophocles, more related than you know

raddevus — Mon, 22 Jul 2024 22:22:00 GMT

While working on a SPA I had some CSS that I was applying on the click of a button.
When the button was clicked, it would make one or the other DIVs go fullscreen (except for a small portion at the top where the nav bar was).

Imagine you have these two divs -- one yellow and one cyan;

CSS

#first{
  background: yellow;
}

#second{
  background: cyan;
}

Then when you click a button in the navbar it would make one or the other go fullscreen by applying a fullscreen CSS class.
It worked great & I was very happy with the simplicity of it all.
If you really want to see it work (toggle), take a look at this simple jsfiddle[^].

CSS

.fullScreen{
  width: 100%;
  height: 90%;
  z-index: 20;
  position: absolute;
  top: 12%;
  padding: 10pt;
}

Here's the button click code.

JavaScript

// select the div and add the style
document.querySelector("#first").classList.add("fullScreen");
// remove style from other div so it isn't fullscreen
document.querySelector("#second").classList.remove("fullScreen");
// vice versa for the other div -- not showing all the toggle code

It Worked, Then Didn't!
It was all working. I copied the code to another project and had it all set up.
But suddenly clicking the button wouldn't do the fullscreen. I tried all manner of things.
Was the button click working? I added an alert() and saw the button was working.
I was going out of my bleedin' mind.
Then I looked real hard at the styles that I had copied to the new project.
Can You See It?
Do you see the problem?

CSS

#first{
  background: yellow;
}

#second{
  background: cyan;
};

.fullScreen{
  width: 100%;
  height: 90%;
  z-index: 20;
  position: absolute;
  top: 12%;
  padding: 10pt;
}

Oy!! I have only myself to blame.

As Sophocles said:
The keenest sorrow is to recognize ourselves as the sole cause of all our adversities.

Sophocles was obviously a software developer.

Linux C PreProcessor: Who Knew?

raddevus — Thu, 04 Jul 2024 16:26:00 GMT

I'm going through a book right now which is fantastic!
It's the best intro to OSes (how they are designed/programmed) I believe you'll ever read.

First of all, you can read it for FREE online (PDFs).
Operating Systems: Three Easy Pieces[^]

Have you read the book? It's fantastic because it starts out with simple code examples (in C) that teach one specific point at a time. Amazing!

If you've never read it, please skip all the (intro nonsense) & go right for the meat (to get an idea of how great the book is). Read this chapter[^] (be aware this will open the PDF in your browser) & I believe you'll be convinced how great the book is too.

And Now For the Weird & Wonderful
While examining the common_threads.h file for the 3rd example I stumbled upon these lines:

#ifdef __linux__
#include <semaphore.h>
#endif

I always wonder about strange things like that and in this case I thought, "Where is the __linux__ defined?"

I looked it up and discovered Gnu docs for the C PreCompiler (cpp exe)[^].

I tried the command they suggested:

$ cpp -dM

But when I did I could see that cpp was running but just had an empty string.

You actually have to point it at an exe and it'll pull out all the preprocessor commands. What!?!

$ cpp -dM ./threadx

When I ran that I saw a huge list of PreProcess commands. Huge!

I then ran it thru grep like this:

$ cpp -dM ./iox | grep -i linux

I saw the following!!

C++

#define __linux 1
#define __gnu_linux__ 1
#define linux 1
#define __linux__ 1

So, I can see that over the years the convention to determine which OS the compiler is running on has changed.

Wow, things get messy as time goes on, don't they.

BONUS
Here's my favorite pre-processor define I found in the list.

C++

#define __FLT128_DENORM_MIN__ 6.47517511943802511092443895822764655e-4966F128

Does this scare anyone else?

honey the codewitch — Thu, 04 Jul 2024 10:44:00 GMT

In LVGL you can set an image source to either be a file path or a structure.

C++

lv_obj_t* ui_img = lv_img_create(ui_screen);
lv_img_dsc_t img_dsc;
img_dsc.header.always_zero = 0;
img_dsc.header.cf = LV_IMG_CF_RAW;
img_dsc.header.w = 800;
img_dsc.header.h = 480;
img_dsc.data_size = 800*480*LV_COLOR_DEPTH/8;
uint8_t *img_mem = (uint8_t*)ps_malloc(img_dsc.data_size);
img_dsc.data = img_mem;
memset(img_mem,0,img_dsc.data_size);
lv_img_set_src(ui_img,&img_dsc);

That's one option.

Here's another

C++

lv_obj_t* ui_img = lv_img_create(ui_screen);
lv_img_set_src(ui_img,"A:/minou_480.jpg");

The lv_img_set_src() function takes a void* for the second argument and either accepts an instance of a lv_img_dsc_t structure or a string!

Worse, there's no lv_img_dsc_init() function to set the struct to a known state (with for example, a magic cookie in it that can be used to flag it as the structure rather than a string)

Ultimately here's how it checks:

C++

if(u8_p[0] >= 0x20 && u8_p[0] <= 0x7F)

where u8_p[0] is the first byte of the source argument.

This is in battle tested production code used in many many devices in the real world.

Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix

What the hell GCC, again

k5054 — Tue, 02 Jul 2024 21:32:00 GMT

Given

#include <string.h>

void swap(char foo[10][20], int i1, int i2)
{
    if(i1 != i2)
    {
        char buff[20];
        strcpy(buff, foo[i1]);
        strcpy(foo[i1], foo[i2]);
        strcpy(foo[i2], buff);
    }
}

when compiling with any optimization level above -O0, gcc complains about the second strcpy, saying

warning: ‘strcpy’ accessing 1 byte at offsets [-4611686018427387904, 4611686018427387903] and [-4611686018427387904, 4611686018427387903] overlaps 1 byte at offset [-4611686018427387904, 199] [-Wrestrict]

clang doesn't complain, even at -O3. I think what gcc is trying to tell me is that there is an issue when i1 == i2, even though there's a test to not swap if i1 == i2! If I replace i1, i2 with integer values (eg. 1, 2) the warning goes away! Weird.
So far, the only way I've found to stop gcc from issuing a warning is to use memcpy instead of strcpy. Though both have restrict qualifiers to both arguments.
Or maybe I'm missing something?

"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown

Dynamic SQL

Richard Andrew x64 — Sun, 30 Jun 2024 19:43:00 GMT

Has anyone ever seen a DB stored procedure where the queries weren't written using SQL, but rather using string concatenation to build the queries, and then submitting the queries with the EXEC command?

I can't think of a more horrifically error-prone way of coding in T-SQL. But I see this from a prominent maker of Warehouse Management Systems.

The first time I ever saw that, I was taken aback because I couldn't understand why anyone would do that. But then I saw that it was done so that the queries could be written to target different databases, tables, and columns depending upon the values of local variables.

So even something as weird and wonderful as that has a use. I wonder if any other RDMS has a more elegant solution?

EDIT:

I realize that the queries could still be written using regular T-SQL, but in a more structured way. But I see that this strange practice waas done for the sake of simpler, straight-line code.

The difficult we do right away...
...the impossible takes slightly longer.

How, VS Code? This is amazing.

honey the codewitch — Sun, 23 Jun 2024 00:51:00 GMT

The intellisense for C++ in VS Code - at least when it works, is nothing short of incredible.

C++

template<size_t BitDepth>
using bgrx_pixel = pixel<
	channel_traits<channel_name::B,(BitDepth/4)>,
    channel_traits<channel_name::G,((BitDepth/4)+(BitDepth%4))>,
    channel_traits<channel_name::R,(BitDepth/4)>,
	channel_traits<channel_name::nop,(BitDepth/4)>    
>;

using rgb18_pixel = pixel<
    channel_traits<channel_name::R,6>,
    channel_traits<channel_name::nop,2>,
    channel_traits<channel_name::G,6>,
    channel_traits<channel_name::nop,2>,
    channel_traits<channel_name::B,6>,
    channel_traits<channel_name::nop,2>
>;

What you're looking at is two arbitrarily defined pixels. One is N-bit pixel where 3/4 of the bits are used, and the second example is a 24-bit pixel where 18-bits are used.

That's not really important, but the channel names are, because consider this:

C++

rgb18_pixel::is_color_model<
            channel_name::R,
            channel_name::G,
            channel_name::B>::value

If you know C++ you can tell there's metaprogramming magic here. What I'm doing is querying a "list" of channel traits at compile time looking for ones with particular names.

The thing is, if you hover over value, the extension will resolve it to true in the tooltip that pops up - no easy feat.

More impressive even is this:

C++

using color18_t = color<rgb18_pixel>;
auto px = color18_t::gray;

It will determine the actual numeric value for that color and display it when you hover over "gray"
(2155905024)

You think that's easy? No.

C++

constexpr static const PixelType gray = convert<source_type,PixelType>(color<PixelType>::source_type(true, 
    0.501960784313725, 
    0.501960784313725, 
    0.501960784313725));

Notice it's running a constexpr function convert() to get the destination pixel format. This is a non-trivial function.

So one of two things is happening here.

Either the C++ extension for VS Code has a compliant C++ compiler front and middle built in (I suspect it does) or it is managing to link itself to existing compilers like GCC tightly enough to determine this output (which doesn't seem possible to me)

Either way, go Microsoft.

Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix

What the hell gcc?

honey the codewitch — Tue, 18 Jun 2024 07:20:00 GMT

C++

float mpu6886::inv_sqrt(float x) {
    float halfx = 0.5f * x;
    float y     = x;
// required, or "y is unintialized":
#pragma GCC diagnostic ignored "-Wuninitialized"
#pragma GCC diagnostic ignored "-Wstrict-aliasing"
    long i = *(long *)&y;
    i      = 0x5f3759df - (i >> 1);
    y      = *(float *)&i;
#pragma GCC diagnostic warning "-Wuninitialized"
#pragma GCC diagnostic warning "-Wstrict-aliasing"
    y = y * (1.5f - (halfx * y * y));
    return y;
}

Tell me how y is uninitialized? This isn't the first time I've encountered this.

Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix

WTF-8

PIEBALDconsult — Tue, 18 Jun 2024 04:40:00 GMT

Reviewing a CSV file today (which already has inconsistent quotes and such), I noticed it has a few characters (e.g. non-breaking space) encoded as UTF-8 -- fine, no big deal. But they still look odd after decoding... ah, they're encoded as UTF-8 twice... double-UTF-8.

So now I have to write a recursive UTF-8 decoder... Why doesn't .net simply do that to begin with? <<== That's a rhetorical question.

It'll be breakfast at Milliways again.

Edit: 4/20 -- I have a working recursive UTF-8 decoding algorithm, in a custom decoder for a custom encoding (derived from the built-in UTF-8 encoding, so encoding should be as per normal).

What was unexpected was that the GetString method of the encoding didn't call the custom Decoder.
I just had a look at the refercence code GetString and I see:

// Returns a string containing the decoded representation of a range of
// bytes in a byte array.
//
// Internally we override this for performance
//
[Pure]
public virtual String GetString(byte[] bytes, int index, int count)
{
    return new String(GetChars(bytes, index, count));
}

Does that mean that it doesn't actually use my decoder?
Shouldn't it call GetDecoder() and use that decoder?
(I'm not experienced at reading the reference source.)
I'll get back to it on Monday.

Edit: 4/21 -- Reading some more about UTF-8 on the 'pedia, I see:

The Unicode Standard requires decoders to
"... treat any ill-formed code unit sequence as an error condition. This guarantees that it will neither interpret nor emit an ill-formed code unit sequence."

and

The standard also recommends replacing each error with the replacement character "�" (U+FFFD).

Which I choose not to do...

These recommendations are not often followed.

But it makes me think that the few U+FFFD characters I see in the file may have begun as unencoded characters which were errantly read with a UTF-8 decoder. Which means that the file I have is in even worse condition than I thought.
Anyway, my current decoder is quite permissive in what it accepts -- preferring not to throw exceptions, but rather pass any errant bytes along to the caller. I will likely alter that next week.

Edit: 4/22 -- A rough logic diagram of my algorithm.

         --------------------------------------------------------------------
         | My custom Decoder                                                |
         |                                                                  |
bytes ---------> Is UTF-8 encoded multi-byte?---NO----------------------------- chars -->
         |   ^                              |                               |
         |   |                              |    --------------------       |
         |   |                              |    |                  |       |
         |   |                              YES----> UTF-8 decoder ----V    |
         |   |                                   |__________________|  |    |
         |   |                                                         |    |
         |   ^---------------------------------------------------------<    |
         |                                                                  |
         |__________________________________________________________________|

The thing to remember is that the UTF-8 Decoder will only ever be presented with byte sequences which are (or appear to be) valid UTF-8 encoded multi-byte characters. Anything else is passed along unchanged, this includes single-byte UTF-8 encoded characters.

I may need to implement a UTF-8 Encoder which won't double-encode UTF-8 characters.

.NET Core & (auto)binding: Is it a bug?

raddevus — Sun, 16 Jun 2024 15:15:00 GMT

My career seems to be entirely described by the following:

"Use a simple technology to do a thing that 80% of Devs take for granted and who also tell you it works, but discovering that the thing doesn't actually work the way they say it works."

Here's the latest. I will try to keep it short (because I'm going to write an article on it, but I can't wait to share this one because it is so weird (from multiple angles)).

1) JavaScript FormData Posted To Backend Is All Strings
Mabye a lot of you know this, but all of the values in the following (real) example end up being strings when they get to the backend.

JavaScript

//first notice that I'm appending two items to the formData.
// 1. string uuid
// 2. journalEntry object with numerous values

var formData = new FormData();
formData.append("uuid",currentUuid);

var entryId = 9;
var jentry = {
        Id:entryId,
        Title: titleText,
        Note: noteText,
        Created: createdDate,
        Updated: null
    };

// You have to do this weird thing to add the data to FormData.

 for (var key in jentry) {
        formData.append(key, jentry[key]);
   }

Odd, But Acceptable
Ok, so the point of that is that all of the values in the jentry object are converted to string values. That means Updated = "null" (string) and the Id = "9".
This is odd, to me, but acceptable.
If you refute this, please provide citations. I've searched far & wide and asked Copilot -- all says they are strings when they hit the backend.

Now It Gets Real Weird
My WebAPI method which gets called by the JS Fetch with the previously shown FormData looks like:

public ActionResult Save([FromForm] String uuid,[FromForm] JournalEntry jentry)

AutoBinding In .NET Core Works With JS Fetch
1. The JS Fetch works.
2. The C# JournalEntry is created from the data posted via the FormData variables.
3. I can examine the data in the C# JournalEntry object and (almost) everything looks fine.

Autobinding Ignores The Id Value!
However, at some point I needed the Id value which was being passed in.
But I noticed that the Id value in the C# object was always ZERO Id = 0.
FormData Value Is Non-Zero, But Autobound Object Is 0
But, keep in mind that the FormData object shown above is passing in a non-zero value for Id (9 in the example.

What!?!

Why Is This Happening?

The only thing I could guess is that since the Id value (from the FormData) was being passed as a String that the autobinding just ignores the value and sets it to 0.

Here's How My C# Object (Used for Autobinding) Is Defined

public class JournalEntry{
    public Int64 Id{get;set;}
    public String? Title{get;set;}
    public String Note{get;set;}
    public String Created{get;set;}
    public String? Updated{get;set;}
}

Yes, the point is that the Id is an Int64 (not a string).

This Part Should Alarm You!!! This Should Be The Bug
So, somehow the autobinder is able to bind the JournalEntry to the FormData object but it just ignores the Id value and sets it to 0!!!!

Why?? !! Please someone explain it to me.

A "Workaround" Test
I altered my JournalEntry class so the Id is a String

public class JournalEntry{
    public String Id{get;set;}
   // ....snip....

and posted the data again.

Autobinder Works! What?!
After that change, the autobinder sets the Id value properly (non-zero value that is read from FormData).

Not What I Expected
This is not what I expected. JSON data is _supposed_ to get autobound to the C# object, right?

Just Binds the Parts It Wants To Bind?
It's weird because it doesn't fail to bind it just skips parts of the object that it wants to skip.
I could accept it if it failed to bind because it was the wrong type.

Article Is Coming Later Today
This was long but I will be writing it up in an article with associated examples and an example project you'll be able to download and try for yourself.

Untested Backups with IonicZip

kmoorevs — Sun, 02 Jun 2024 15:30:00 GMT

Over a decade ago, I wrote a SQL Server backup/rotation manager. Backups are zipped and password protected using IonicZip, then copied to a local repository on another disk, and optionally pushed out to an FTP resource. This is handy for when I find myself working on the laptop away from the home/office. This system has been used on multiple servers without issues.

A couple of weeks ago, I started using it on a newish Azure VM for one of our latest projects to manage 2 customer databases. It appeared to be working fine...backups/zips/copies all getting created with no errors...or so I thought. Yesterday, I was away from the office and decided to grab the previous day's backups and restore them on my laptop. Using 7-zip, the zips extracted, but with a CRC error detected. Of course, the backups were useless. Native windows zip refused to extract anything, failing with a generic error message. 'unrecognized error'. Every backup from that system was corrupted!

Backups from the other 2 systems are/were fine...one of the other systems is also an Azure VM with practically identical setups and has been working fine for years.

I'll skip the troubleshooting details and get to the fix. IonicZip has a property that I had never heard of before, and which until now had not been important: ParallelDeflateThreshold which needed to be set to -1. Doing so fixed the problem. If I understand correctly, IonicZip has a known problem with files that compress to < 4MB. In my case, mine were slightly over 2MB compressed. All of my other backups are much larger which is perhaps the reason why I've never seen this problem before.

At any rate, I wanted to post this here in case someone else here is using this component and not aware of this issue. The bottom line is, test your backups! Have a great weekend!

"Go forth into the source" - Neal Morse
"Hope is contagious"

Looking at the very topmost line ...

trønderen — Sat, 01 Jun 2024 21:21:00 GMT

... it occurred to me: What if CP itself, or any subsystem employed, has chosen to use the top 8 bits e.g. to flag privileges or other user properties, leaving only 24 bits for the member number?

Religious freedom is the freedom to say that two plus two make five.

Blessed endian mismatches collide with progress

honey the codewitch — Sat, 01 Jun 2024 17:30:00 GMT

Almost all embedded MCUs are little endian.
Almost all display controllers that can connect to them are big endian.

My graphics library builds pixels in big endian order on little endian machines as a consequence. It's just more efficient.

LVGL is another embedded graphics library - one I contribute to - and they removed a feature on version 9+ where you could set it to swap the bytes on a 16 bit color value. This is to compensate for the endian issues.

Not swapping during the draw operation means you need to scan and rearrange the transfer buffer before you send it to the display.

C++

evoid lcd_flush_display( lv_display_t *disp, const lv_area_t *area, uint8_t * px_map) {
    size_t count = (area->x2-area->x1+1)*(area->y2-area->y1+1);
    for(int i = 0;i<count;++i) {
        uint16_t* p = &((uint16_t*)px_map)[i];
        *p = ((*p<<8)&0xFF00)|((*p>>8)&0xFF);
    }
    esp_lcd_panel_draw_bitmap(lcd_handle,area->x1,area->y1,area->x2+1,area->y2+1,px_map);
    LV_UNUSED(disp);
}

This is less efficient. It's also ugly. This is what's for dinner now in LVGL. This is "progress".

The worst part is I understand and even sort of agree with why they did it.

The issue is multiple displays, and the fact that some displays may not need the swap, perhaps because they're monochrome or something. Previously prior to 8 LVGL simply didn't support that scenario because the swap option was a #define (LVGL is C, not C++) and it applied to all displays as a consequence.

But to remove it entirely seems like it was a decision guided by expediency more than anything. It's unfortunate.

And all of it reminds me of why I hate the fact that humans couldn't universally agree on endian order.

Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix

implementing interface method, same signature, from two interfaces

raddevus — Thu, 25 Apr 2024 19:55:00 GMT

Here's a little test for you.

Does this code compile?

public interface IStorage{
    int Save();
}

public interface IPersist{
    int Save();
}

public class SaveImplementor : IStorage, IPersist{
    public int Save(){
        return 1;
    }
}

I'm implementing two interfaces which contain the same virtual method signature.

Well, it seems a little odd to me.

Obviously, if you want the separate implementations you have to write them explicitly.

Like this:

public class SaveImplementor : IStorage, IPersist{

    int IStorage.Save(){
        return 1;
    }

    int IPersist.Save(){
        return 2;
    }
}

IMPORTANT NOTE: Notice that in the first example you HAVE to include the public modifier on the method implementation.

HOWEVER, on the second example where you explicitly implement the Interface method you CANNOT include the public modifier.

I'm filing this one under weird.

But, I guess I accept it. I have to, or else the C# compiler doesn't accept me.

Answer - The first example does indeed compile.

EDIT

Oh, and after I posted that, I went back and new'd up a SaveImplementor() and then I couldn't figure out how to call either of those explicit methods.
Hmm... It's got me thinking now.

EDIT 2
Here's the simple example that explains the explicit implementation: Explicit Interface Implementation - C# Programming Guide - C# | Microsoft Learn[^] .

Given enough eyeballs - a Sunday rant...

Mircea Neacsu — Sun, 21 Apr 2024 17:32:00 GMT

... after a frustrating week, this could be taken as a general rant at the quality of open-source software with applications to particular pieces.

Given enough eyeballs, where are those eyeballs looking? Surely not at libpng[^] - the reference implementation for the PNG format. It is a smallish library of about 20 kLOC but the configuration file with all the possible options has over 200 different options. That makes for 200x200 = 40k potentially different ways you could build the library. Either that or some of the options are redundant.

The code quality is atrocious. I understand that it's a project started in the '90es but that's no excuse for not cleaning it up from time to time. You cannot let one test program get to 12000 lines in a single file. And those 12000 lines are full of miracles like parameters and structure members called this! Don't you worry! At the beginning of the file there is this fragment:

C++

#ifdef __cplusplus
#  define this not_the_cpp_this
#  define new not_the_cpp_new

Also, if the byzantine compile time configuration options make it impossible for the program to run would you think of throwing an error using a #error directive? NO, good quality open-source code just wraps the whole program in an #if block with the #else clause, 12000 lines below:

C++

#else /* write or low level APIs not supported */
int main(void)
{
   fprintf(stderr,
      "pngvalid: no low level write support in libpng, all tests skipped\n");
   /* So the test is skipped: */
   return SKIP;
}
#endif

Remember: these are compile time conditions; why would you fail at run time?

Have you heard of semantic versioning? Well, check this out (straight from the LIBPNG) web site:

Quote:
At present, there are eight branches:

master (actively developed)
libpng16 (equivalent to master)
libpng17 (frozen, last updated on 2017-Sep-03)
libpng15 (frozen, last updated on 2017-Sep-28)
libpng14 (frozen, last updated on 2017-Sep-28)
libpng12 (frozen, last updated on 2017-Sep-28)
libpng10 (frozen, last updated on 2017-Aug-24)
libpng00 (frozen, last updated on 1998-Mar-08)

These translate in version numbers as 1.6.x, 1.7.x, 1.5.x, and so on. So, let me get this straight: version 1.7 is frozen and version 1.6 is actively developed? Have you guys ran out of numbers? And, guess what, in code you find many tests like these:

C++

#if PNG_LIBPNG_VER >= 10700
        if (!for_background && image->bit_depth < 8)
          image->bit_depth = image->sample_depth = 8;
#endif

???
I will stop here although, after a week of frustrations, I could go on and on.

There is a well-known commencement speech: Make your own bed - University of Texas at Austin 2014 Commencement Address - Admiral William H. McRaven - YouTube[^]. As a developer, and specially as an open-source maintainer, before writing a single line of new code, do everyone a favour: clean the project you are working on; make your own bed!

Mircea

Country code

PIEBALDconsult — Wed, 17 Apr 2024 03:07:00 GMT

Requiring the country code seems unusual (for a site in the U.S.) -- but what would prompt a web developer to make it an elephanting drop-down?!

https://www.codeproject.com/Uploads/Membership/Uploads/2587207/StupidCountryCode.png[^]

SQL (Transact-SQL) needs a proper FOR loop!

PIEBALDconsult — Tue, 02 Apr 2024 03:30:00 GMT

The other day I wrote an SQL function with a bug of the following form:

SQL

DECLARE @i INTEGER = 0

WHILE ( @i < foo )
BEGIN
  IF -- test something
  BEGIN
    -- do stuff

    SET @i = @i + 1
  END
END

I expected the function to be inefficient, but not infinite the first time the test returns false.

.bash_history makes me happy, how about you?

raddevus — Sun, 10 Mar 2024 00:34:00 GMT

I had used Windows since 3.0 (ca 1991) before I switched to main usage of Linux in 2019 so please don't make fun of me for this too much.

I've been working on setting up my .NET Core WebAPIs (hosted under various domains but running on one copy of a DigitalOcean droplet (running Debian)) and setting up the services and forwarding via Nginx and all that. It's all command-line there are a lot of steps that I forget often.

1. set up a service file in /etc/systemd/system/
2. build the WebAPI and deploy it under a folder in /var/www/
3. configure nginx to point at your webAPI
4. create link to the nginx config ln -s /etc/nginx/sites-available/<apiName> /etc/nginx/sites-enabled/

There's a bunch of things and I would lose the commands and forget things I should do.
And, I be forever up-arrowing to get to old commands that I had used.

.bash_history
Then I stumbled upon the .bash_history file and noticed I can open it up in an editor (nano, of course, because I am vim-weak and don't know how to exit vim )

Wow, that is really cool that all those commands are just sitting in there like that so I can now pull them out and save them to a file with some documentation.

Thank you, Linux, it seems like you get better all the time.

I bet you already knew about .bash_history didn't you? Well, try not to laugh at me too hard for only finding it now.

Standards? Eat your heart out, Randall

Peter_in_2780 — Mon, 26 Feb 2024 02:07:00 GMT

Inspired by xkcd: Standards[^] ...
iconv --list produces this:

The following list contains all the coded character sets known.  This does
not necessarily mean that all combinations of these names can be used for
the FROM and TO command line parameters.  One coded character set can be
listed with several different names (aliases).

  437, 500, 500V1, 850, 851, 852, 855, 856, 857, 858, 860, 861, 862, 863, 864,
  865, 866, 866NAV, 869, 874, 904, 1026, 1046, 1047, 8859_1, 8859_2, 8859_3,
  8859_4, 8859_5, 8859_6, 8859_7, 8859_8, 8859_9, 10646-1:1993,
  10646-1:1993/UCS4, ANSI_X3.4-1968, ANSI_X3.4-1986, ANSI_X3.4,
  ANSI_X3.110-1983, ANSI_X3.110, ARABIC, ARABIC7, ARMSCII-8, ARMSCII8, ASCII,
  ASMO-708, ASMO_449, BALTIC, BIG-5, BIG-FIVE, BIG5-HKSCS, BIG5, BIG5HKSCS,
  BIGFIVE, BRF, BS_4730, CA, CN-BIG5, CN-GB, CN, CP-AR, CP-GR, CP-HU, CP037,
  CP038, CP273, CP274, CP275, CP278, CP280, CP281, CP282, CP284, CP285, CP290,
  CP297, CP367, CP420, CP423, CP424, CP437, CP500, CP737, CP770, CP771, CP772,
  CP773, CP774, CP775, CP803, CP813, CP819, CP850, CP851, CP852, CP855, CP856,
  CP857, CP858, CP860, CP861, CP862, CP863, CP864, CP865, CP866, CP866NAV,
  CP868, CP869, CP870, CP871, CP874, CP875, CP880, CP891, CP901, CP902, CP903,
  CP904, CP905, CP912, CP915, CP916, CP918, CP920, CP921, CP922, CP930, CP932,
  CP933, CP935, CP936, CP937, CP939, CP949, CP950, CP1004, CP1008, CP1025,
  CP1026, CP1046, CP1047, CP1070, CP1079, CP1081, CP1084, CP1089, CP1097,
  CP1112, CP1122, CP1123, CP1124, CP1125, CP1129, CP1130, CP1132, CP1133,
  CP1137, CP1140, CP1141, CP1142, CP1143, CP1144, CP1145, CP1146, CP1147,
  CP1148, CP1149, CP1153, CP1154, CP1155, CP1156, CP1157, CP1158, CP1160,
  CP1161, CP1162, CP1163, CP1164, CP1166, CP1167, CP1250, CP1251, CP1252,
  CP1253, CP1254, CP1255, CP1256, CP1257, CP1258, CP1282, CP1361, CP1364,
  CP1371, CP1388, CP1390, CP1399, CP4517, CP4899, CP4909, CP4971, CP5347,
  CP9030, CP9066, CP9448, CP10007, CP12712, CP16804, CPIBM861, CSA7-1, CSA7-2,
  CSASCII, CSA_T500-1983, CSA_T500, CSA_Z243.4-1985-1, CSA_Z243.4-1985-2,
  CSA_Z243.419851, CSA_Z243.419852, CSDECMCS, CSEBCDICATDE, CSEBCDICATDEA,
  CSEBCDICCAFR, CSEBCDICDKNO, CSEBCDICDKNOA, CSEBCDICES, CSEBCDICESA,
  CSEBCDICESS, CSEBCDICFISE, CSEBCDICFISEA, CSEBCDICFR, CSEBCDICIT, CSEBCDICPT,
  CSEBCDICUK, CSEBCDICUS, CSEUCKR, CSEUCPKDFMTJAPANESE, CSGB2312, CSHPROMAN8,
  CSIBM037, CSIBM038, CSIBM273, CSIBM274, CSIBM275, CSIBM277, CSIBM278,
  CSIBM280, CSIBM281, CSIBM284, CSIBM285, CSIBM290, CSIBM297, CSIBM420,
  CSIBM423, CSIBM424, CSIBM500, CSIBM803, CSIBM851, CSIBM855, CSIBM856,
  CSIBM857, CSIBM860, CSIBM863, CSIBM864, CSIBM865, CSIBM866, CSIBM868,
  CSIBM869, CSIBM870, CSIBM871, CSIBM880, CSIBM891, CSIBM901, CSIBM902,
  CSIBM903, CSIBM904, CSIBM905, CSIBM918, CSIBM921, CSIBM922, CSIBM930,
  CSIBM932, CSIBM933, CSIBM935, CSIBM937, CSIBM939, CSIBM943, CSIBM1008,
  CSIBM1025, CSIBM1026, CSIBM1097, CSIBM1112, CSIBM1122, CSIBM1123, CSIBM1124,
  CSIBM1129, CSIBM1130, CSIBM1132, CSIBM1133, CSIBM1137, CSIBM1140, CSIBM1141,
  CSIBM1142, CSIBM1143, CSIBM1144, CSIBM1145, CSIBM1146, CSIBM1147, CSIBM1148,
  CSIBM1149, CSIBM1153, CSIBM1154, CSIBM1155, CSIBM1156, CSIBM1157, CSIBM1158,
  CSIBM1160, CSIBM1161, CSIBM1163, CSIBM1164, CSIBM1166, CSIBM1167, CSIBM1364,
  CSIBM1371, CSIBM1388, CSIBM1390, CSIBM1399, CSIBM4517, CSIBM4899, CSIBM4909,
  CSIBM4971, CSIBM5347, CSIBM9030, CSIBM9066, CSIBM9448, CSIBM12712,
  CSIBM16804, CSIBM11621162, CSISO4UNITEDKINGDOM, CSISO10SWEDISH,
  CSISO11SWEDISHFORNAMES, CSISO14JISC6220RO, CSISO15ITALIAN, CSISO16PORTUGESE,
  CSISO17SPANISH, CSISO18GREEK7OLD, CSISO19LATINGREEK, CSISO21GERMAN,
  CSISO25FRENCH, CSISO27LATINGREEK1, CSISO49INIS, CSISO50INIS8,
  CSISO51INISCYRILLIC, CSISO58GB1988, CSISO60DANISHNORWEGIAN,
  CSISO60NORWEGIAN1, CSISO61NORWEGIAN2, CSISO69FRENCH, CSISO84PORTUGUESE2,
  CSISO85SPANISH2, CSISO86HUNGARIAN, CSISO88GREEK7, CSISO89ASMO449, CSISO90,
  CSISO92JISC62991984B, CSISO99NAPLPS, CSISO103T618BIT, CSISO111ECMACYRILLIC,
  CSISO121CANADIAN1, CSISO122CANADIAN2, CSISO139CSN369103, CSISO141JUSIB1002,
  CSISO143IECP271, CSISO150, CSISO150GREEKCCITT, CSISO151CUBA,
  CSISO153GOST1976874, CSISO646DANISH, CSISO2022CN, CSISO2022JP, CSISO2022JP2,
  CSISO2022KR, CSISO2033, CSISO5427CYRILLIC, CSISO5427CYRILLIC1981,
  CSISO5428GREEK, CSISO10367BOX, CSISOLATIN1, CSISOLATIN2, CSISOLATIN3,
  CSISOLATIN4, CSISOLATIN5, CSISOLATIN6, CSISOLATINARABIC, CSISOLATINCYRILLIC,
  CSISOLATINGREEK, CSISOLATINHEBREW, CSKOI8R, CSKSC5636, CSMACINTOSH,
  CSNATSDANO, CSNATSSEFI, CSN_369103, CSPC8CODEPAGE437, CSPC775BALTIC,
  CSPC850MULTILINGUAL, CSPC858MULTILINGUAL, CSPC862LATINHEBREW, CSPCP852,
  CSSHIFTJIS, CSUCS4, CSUNICODE, CSWINDOWS31J, CUBA, CWI-2, CWI, CYRILLIC, DE,
  DEC-MCS, DEC, DECMCS, DIN_66003, DK, DS2089, DS_2089, E13B, EBCDIC-AT-DE-A,
  EBCDIC-AT-DE, EBCDIC-BE, EBCDIC-BR, EBCDIC-CA-FR, EBCDIC-CP-AR1,
  EBCDIC-CP-AR2, EBCDIC-CP-BE, EBCDIC-CP-CA, EBCDIC-CP-CH, EBCDIC-CP-DK,
  EBCDIC-CP-ES, EBCDIC-CP-FI, EBCDIC-CP-FR, EBCDIC-CP-GB, EBCDIC-CP-GR,
  EBCDIC-CP-HE, EBCDIC-CP-IS, EBCDIC-CP-IT, EBCDIC-CP-NL, EBCDIC-CP-NO,
  EBCDIC-CP-ROECE, EBCDIC-CP-SE, EBCDIC-CP-TR, EBCDIC-CP-US, EBCDIC-CP-WT,
  EBCDIC-CP-YU, EBCDIC-CYRILLIC, EBCDIC-DK-NO-A, EBCDIC-DK-NO, EBCDIC-ES-A,
  EBCDIC-ES-S, EBCDIC-ES, EBCDIC-FI-SE-A, EBCDIC-FI-SE, EBCDIC-FR,
  EBCDIC-GREEK, EBCDIC-INT, EBCDIC-INT1, EBCDIC-IS-FRISS, EBCDIC-IT,
  EBCDIC-JP-E, EBCDIC-JP-KANA, EBCDIC-PT, EBCDIC-UK, EBCDIC-US, EBCDICATDE,
  EBCDICATDEA, EBCDICCAFR, EBCDICDKNO, EBCDICDKNOA, EBCDICES, EBCDICESA,
  EBCDICESS, EBCDICFISE, EBCDICFISEA, EBCDICFR, EBCDICISFRISS, EBCDICIT,
  EBCDICPT, EBCDICUK, EBCDICUS, ECMA-114, ECMA-118, ECMA-128, ECMA-CYRILLIC,
  ECMACYRILLIC, ELOT_928, ES, ES2, EUC-CN, EUC-JISX0213, EUC-JP-MS, EUC-JP,
  EUC-KR, EUC-TW, EUCCN, EUCJP-MS, EUCJP-OPEN, EUCJP-WIN, EUCJP, EUCKR, EUCTW,
  FI, FR, GB, GB2312, GB13000, GB18030, GBK, GB_1988-80, GB_198880,
  GEORGIAN-ACADEMY, GEORGIAN-PS, GOST_19768-74, GOST_19768, GOST_1976874,
  GREEK-CCITT, GREEK, GREEK7-OLD, GREEK7, GREEK7OLD, GREEK8, GREEKCCITT,
  HEBREW, HP-GREEK8, HP-ROMAN8, HP-ROMAN9, HP-THAI8, HP-TURKISH8, HPGREEK8,
  HPROMAN8, HPROMAN9, HPTHAI8, HPTURKISH8, HU, IBM-803, IBM-856, IBM-901,
  IBM-902, IBM-921, IBM-922, IBM-930, IBM-932, IBM-933, IBM-935, IBM-937,
  IBM-939, IBM-943, IBM-1008, IBM-1025, IBM-1046, IBM-1047, IBM-1097, IBM-1112,
  IBM-1122, IBM-1123, IBM-1124, IBM-1129, IBM-1130, IBM-1132, IBM-1133,
  IBM-1137, IBM-1140, IBM-1141, IBM-1142, IBM-1143, IBM-1144, IBM-1145,
  IBM-1146, IBM-1147, IBM-1148, IBM-1149, IBM-1153, IBM-1154, IBM-1155,
  IBM-1156, IBM-1157, IBM-1158, IBM-1160, IBM-1161, IBM-1162, IBM-1163,
  IBM-1164, IBM-1166, IBM-1167, IBM-1364, IBM-1371, IBM-1388, IBM-1390,
  IBM-1399, IBM-4517, IBM-4899, IBM-4909, IBM-4971, IBM-5347, IBM-9030,
  IBM-9066, IBM-9448, IBM-12712, IBM-16804, IBM037, IBM038, IBM256, IBM273,
  IBM274, IBM275, IBM277, IBM278, IBM280, IBM281, IBM284, IBM285, IBM290,
  IBM297, IBM367, IBM420, IBM423, IBM424, IBM437, IBM500, IBM775, IBM803,
  IBM813, IBM819, IBM848, IBM850, IBM851, IBM852, IBM855, IBM856, IBM857,
  IBM858, IBM860, IBM861, IBM862, IBM863, IBM864, IBM865, IBM866, IBM866NAV,
  IBM868, IBM869, IBM870, IBM871, IBM874, IBM875, IBM880, IBM891, IBM901,
  IBM902, IBM903, IBM904, IBM905, IBM912, IBM915, IBM916, IBM918, IBM920,
  IBM921, IBM922, IBM930, IBM932, IBM933, IBM935, IBM937, IBM939, IBM943,
  IBM1004, IBM1008, IBM1025, IBM1026, IBM1046, IBM1047, IBM1089, IBM1097,
  IBM1112, IBM1122, IBM1123, IBM1124, IBM1129, IBM1130, IBM1132, IBM1133,
  IBM1137, IBM1140, IBM1141, IBM1142, IBM1143, IBM1144, IBM1145, IBM1146,
  IBM1147, IBM1148, IBM1149, IBM1153, IBM1154, IBM1155, IBM1156, IBM1157,
  IBM1158, IBM1160, IBM1161, IBM1162, IBM1163, IBM1164, IBM1166, IBM1167,
  IBM1364, IBM1371, IBM1388, IBM1390, IBM1399, IBM4517, IBM4899, IBM4909,
  IBM4971, IBM5347, IBM9030, IBM9066, IBM9448, IBM12712, IBM16804, IEC_P27-1,
  IEC_P271, INIS-8, INIS-CYRILLIC, INIS, INIS8, INISCYRILLIC, ISIRI-3342,
  ISIRI3342, ISO-2022-CN-EXT, ISO-2022-CN, ISO-2022-JP-2, ISO-2022-JP-3,
  ISO-2022-JP, ISO-2022-KR, ISO-8859-1, ISO-8859-2, ISO-8859-3, ISO-8859-4,
  ISO-8859-5, ISO-8859-6, ISO-8859-7, ISO-8859-8, ISO-8859-9, ISO-8859-9E,
  ISO-8859-10, ISO-8859-11, ISO-8859-13, ISO-8859-14, ISO-8859-15, ISO-8859-16,
  ISO-10646, ISO-10646/UCS2, ISO-10646/UCS4, ISO-10646/UTF-8, ISO-10646/UTF8,
  ISO-CELTIC, ISO-IR-4, ISO-IR-6, ISO-IR-8-1, ISO-IR-9-1, ISO-IR-10, ISO-IR-11,
  ISO-IR-14, ISO-IR-15, ISO-IR-16, ISO-IR-17, ISO-IR-18, ISO-IR-19, ISO-IR-21,
  ISO-IR-25, ISO-IR-27, ISO-IR-37, ISO-IR-49, ISO-IR-50, ISO-IR-51, ISO-IR-54,
  ISO-IR-55, ISO-IR-57, ISO-IR-60, ISO-IR-61, ISO-IR-69, ISO-IR-84, ISO-IR-85,
  ISO-IR-86, ISO-IR-88, ISO-IR-89, ISO-IR-90, ISO-IR-92, ISO-IR-98, ISO-IR-99,
  ISO-IR-100, ISO-IR-101, ISO-IR-103, ISO-IR-109, ISO-IR-110, ISO-IR-111,
  ISO-IR-121, ISO-IR-122, ISO-IR-126, ISO-IR-127, ISO-IR-138, ISO-IR-139,
  ISO-IR-141, ISO-IR-143, ISO-IR-144, ISO-IR-148, ISO-IR-150, ISO-IR-151,
  ISO-IR-153, ISO-IR-155, ISO-IR-156, ISO-IR-157, ISO-IR-166, ISO-IR-179,
  ISO-IR-193, ISO-IR-197, ISO-IR-199, ISO-IR-203, ISO-IR-209, ISO-IR-226,
  ISO/TR_11548-1, ISO646-CA, ISO646-CA2, ISO646-CN, ISO646-CU, ISO646-DE,
  ISO646-DK, ISO646-ES, ISO646-ES2, ISO646-FI, ISO646-FR, ISO646-FR1,
  ISO646-GB, ISO646-HU, ISO646-IT, ISO646-JP-OCR-B, ISO646-JP, ISO646-KR,
  ISO646-NO, ISO646-NO2, ISO646-PT, ISO646-PT2, ISO646-SE, ISO646-SE2,
  ISO646-US, ISO646-YU, ISO2022CN, ISO2022CNEXT, ISO2022JP, ISO2022JP2,
  ISO2022KR, ISO6937, ISO8859-1, ISO8859-2, ISO8859-3, ISO8859-4, ISO8859-5,
  ISO8859-6, ISO8859-7, ISO8859-8, ISO8859-9, ISO8859-9E, ISO8859-10,
  ISO8859-11, ISO8859-13, ISO8859-14, ISO8859-15, ISO8859-16, ISO11548-1,
  ISO88591, ISO88592, ISO88593, ISO88594, ISO88595, ISO88596, ISO88597,
  ISO88598, ISO88599, ISO88599E, ISO885910, ISO885911, ISO885913, ISO885914,
  ISO885915, ISO885916, ISO_646.IRV:1991, ISO_2033-1983, ISO_2033,
  ISO_5427-EXT, ISO_5427, ISO_5427:1981, ISO_5427EXT, ISO_5428, ISO_5428:1980,
  ISO_6937-2, ISO_6937-2:1983, ISO_6937, ISO_6937:1992, ISO_8859-1,
  ISO_8859-1:1987, ISO_8859-2, ISO_8859-2:1987, ISO_8859-3, ISO_8859-3:1988,
  ISO_8859-4, ISO_8859-4:1988, ISO_8859-5, ISO_8859-5:1988, ISO_8859-6,
  ISO_8859-6:1987, ISO_8859-7, ISO_8859-7:1987, ISO_8859-7:2003, ISO_8859-8,
  ISO_8859-8:1988, ISO_8859-9, ISO_8859-9:1989, ISO_8859-9E, ISO_8859-10,
  ISO_8859-10:1992, ISO_8859-14, ISO_8859-14:1998, ISO_8859-15,
  ISO_8859-15:1998, ISO_8859-16, ISO_8859-16:2001, ISO_9036, ISO_10367-BOX,
  ISO_10367BOX, ISO_11548-1, ISO_69372, IT, JIS_C6220-1969-RO,
  JIS_C6229-1984-B, JIS_C62201969RO, JIS_C62291984B, JOHAB, JP-OCR-B, JP, JS,
  JUS_I.B1.002, KOI-7, KOI-8, KOI8-R, KOI8-RU, KOI8-T, KOI8-U, KOI8, KOI8R,
  KOI8U, KSC5636, L1, L2, L3, L4, L5, L6, L7, L8, L10, LATIN-9, LATIN-GREEK-1,
  LATIN-GREEK, LATIN1, LATIN2, LATIN3, LATIN4, LATIN5, LATIN6, LATIN7, LATIN8,
  LATIN9, LATIN10, LATINGREEK, LATINGREEK1, MAC-CENTRALEUROPE, MAC-CYRILLIC,
  MAC-IS, MAC-SAMI, MAC-UK, MAC, MACCYRILLIC, MACINTOSH, MACIS, MACUK,
  MACUKRAINIAN, MIK, MS-ANSI, MS-ARAB, MS-CYRL, MS-EE, MS-GREEK, MS-HEBR,
  MS-MAC-CYRILLIC, MS-TURK, MS932, MS936, MSCP949, MSCP1361, MSMACCYRILLIC,
  MSZ_7795.3, MS_KANJI, NAPLPS, NATS-DANO, NATS-SEFI, NATSDANO, NATSSEFI,
  NC_NC0010, NC_NC00-10, NC_NC00-10:81, NF_Z_62-010, NF_Z_62-010_(1973),
  NF_Z_62-010_1973, NF_Z_62010, NF_Z_62010_1973, NO, NO2, NS_4551-1, NS_4551-2,
  NS_45511, NS_45512, OS2LATIN1, OSF00010001, OSF00010002, OSF00010003,
  OSF00010004, OSF00010005, OSF00010006, OSF00010007, OSF00010008, OSF00010009,
  OSF0001000A, OSF00010020, OSF00010100, OSF00010101, OSF00010102, OSF00010104,
  OSF00010105, OSF00010106, OSF00030010, OSF0004000A, OSF0005000A, OSF05010001,
  OSF100201A4, OSF100201A8, OSF100201B5, OSF100201F4, OSF100203B5, OSF1002011C,
  OSF1002011D, OSF1002035D, OSF1002035E, OSF1002035F, OSF1002036B, OSF1002037B,
  OSF10010001, OSF10010004, OSF10010006, OSF10020025, OSF10020111, OSF10020115,
  OSF10020116, OSF10020118, OSF10020122, OSF10020129, OSF10020352, OSF10020354,
  OSF10020357, OSF10020359, OSF10020360, OSF10020364, OSF10020365, OSF10020366,
  OSF10020367, OSF10020370, OSF10020387, OSF10020388, OSF10020396, OSF10020402,
  OSF10020417, PT, PT2, PT154, R8, R9, RK1048, ROMAN8, ROMAN9, RUSCII, SE, SE2,
  SEN_850200_B, SEN_850200_C, SHIFT-JIS, SHIFTJISX0213, SHIFT_JIS,
  SHIFT_JISX0213, SJIS-OPEN, SJIS-WIN, SJIS, SS636127, STRK1048-2002,
  ST_SEV_358-88, T.61-8BIT, T.61, T.618BIT, TCVN-5712, TCVN, TCVN5712-1,
  TCVN5712-1:1993, THAI8, TIS-620, TIS620-0, TIS620.2529-1, TIS620.2533-0,
  TIS620, TS-5881, TSCII, TURKISH8, UCS-2, UCS-2BE, UCS-2LE, UCS-4, UCS-4BE,
  UCS-4LE, UCS2, UCS4, UHC, UJIS, UK, UNICODE, UNICODEBIG, UNICODELITTLE,
  US-ASCII, US, UTF-7, UTF-8, UTF-16, UTF-16BE, UTF-16LE, UTF-32, UTF-32BE,
  UTF-32LE, UTF7, UTF8, UTF16, UTF16BE, UTF16LE, UTF32, UTF32BE, UTF32LE,
  VISCII, WCHAR_T, WIN-SAMI-2, WINBALTRIM, WINDOWS-31J, WINDOWS-874,
  WINDOWS-936, WINDOWS-1250, WINDOWS-1251, WINDOWS-1252, WINDOWS-1253,
  WINDOWS-1254, WINDOWS-1255, WINDOWS-1256, WINDOWS-1257, WINDOWS-1258,
  WINSAMI2, WS2, YU

1179 by my count. No, I am not going to find out how many are unique and how many are aliased.

Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012

Supporting multiple cores from bare metal C

honey the codewitch — Tue, 13 Feb 2024 17:17:00 GMT

I always wondered what a bare metal C implementation - the kind you'd use to write even parts of low level boot loader code would do to expose things like a 2nd core.

Or rather, how do you use a 2nd core without a scheduler? I've always kinda wondered about that.

The answer is simple. You activate the core in the bootloader and then get the core to JMP to your code. One main() in effect, for each core.

C++

extern "C" void aux_core_main()
{
    // 2nd core just starts here. Spin a loop. Be happy.
}

Synchronization is a whole different story, but if you don't need to synchronize, why waste any overhead on scheduling?

Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix

Source Generators in C# and TDD misadventure time

honey the codewitch — Wed, 31 Jan 2024 17:30:00 GMT

I'm very new to the source generator technology in C# so bear with me, as my information is probably incomplete or inaccurate but what I've discovered so far is amusing and annoying at the same time.

I tried to get a source generator referenced from one project for use in another project and I was getting weird results when crawling the syntax tree. I don't even know how to google about the results I'm getting back. It's hard to explain, but it breaks the thing.

Creating an incremental generator[^]

I followed this code precisely, and it didn't work on my system.

However, it will work when I invoke the generator to run specifically as part of a unit test. I haven't had as much luck invoking it outside a test framework. I have no idea why this is.

I *believe* (read: hope) it will work when packaged as a NuGet package as well, which is how it was designed to be deployed and used.

Of course, I don't want to deploy a NuGet package of code still in initial development.

The bottom line for all of this is that this leaves me in the position of being forced to perform Test Driven Development in order to make source generators.

I don't know if this is a weirdness with my machine, or perhaps a quirk in this relatively new technology or what, but it's just bizarre to be forced into a particular development paradigm like this.

Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix