The new Visual Studio is working now. I decided that while I had the hood open, it would be a good time to tweak some other things. I had a long list of things that work, but could be made to work better.

Of course little things tend to become big things, and that great alternate design turns out to not be so great. I just accept that this is part of the process of learning and improving. I am not going to bore you with the details. It is mentioned only to provide an excuse for the recent scarcity of blog posts.

Along the way while making these program changes, I create test images. The main motivation is of course to test and explore new ideas. Some of those test images are interesting on their own. I classify these as "work in process" and save them to develop further in the future. For now, I need to keep focus on adding / improving program features.

This one gives an impression of colored lights in a dark room.

My posts have slowed down in the last three months. My program port to VS2022 has been complete for some time now. Previously I described two problems with the port. The first was solved by loading unnecessary dlls to get the compiler to work. The second, AssemblyLoadContext is a poor substitute for AppDomain, has two consequences; it wastes memory and prevents recovery when an add-on crashes or hangs. I grew up in an era where external storage access and memory were expensive. I need to keep reminding myself that this is not a problem in the 21st century. And if an add-on fails, I terminate the run and restart in debug mode. It does not happen often and when it does I usually need the debug tools to find fix the flaws anyway.

Another chaotic swirl.

The next problem with the software port was with AppDomains. An AppDomain is an isolated environment to run a program, or a part of a program. Every program runs in an AppDomain. The main program AppDomain is created when the program starts and taken down when the program exits. You never notice it or think about it. The tricky part is when you want more than one AppDomain.

A second AppDomain is useful with add-on code as described in the last couple of posts. If you load a program add-on into the main AppDomain, you cannot get rid of the add-on without terminating the main program. By loading the add-on into a separate AppDomain, you can discard the AppDomain, and the add-on code when you are done with it. I do this to recover the memory space used by the add-on, and to protect against crashes. The add-on code tends to be more experimental and less tested than the main program code.

My art program is the only program I have that uses more than one AppDomain. So I am deep into the port to VS 2022 when I learn that AppDomain support has been removed from .Net 6. Not changed, just flat out not supported.

The next best thing appears to be the AssemblyLoadContext class. You can load the add-on dll into a separate AssemblyLoadContext. When the add-on is done running the garbage collector eventually runs and frees the space. Well that is the theory at least.

There is a known bug with AssemblyLoadContext garbage collection when it runs WPF (Windows Presentation Foundation) code. WPF creates objects for windows and other display components. Some of these objects are never released, even after the window is closed. That prevents garbage collection. At the time I was discovering these problems the recommended work-around was the ever-so-helpful "just don't do that". In my case, my add-ons often come with custom editors which use WPF, so the recommended "solution" is not feasible. It may have been fixed by now, but I am not in a mood to fight that battle again.

I have given up on AppDomain and AssemblyLoadContext. Computers have so much memory these days, that worrying about add-on code memory use is a misplaced concerned. The memory used by the add-on program code is insignificant compared to the memory used for a single high resolution picture. As for program code defects, I just need to be more careful.

Another exotic formula. Looks like something mixing or flowing.

Continuing my VS2022 porting story. My first attempt to upgrade failed, a few months later I tried again, this time with more realistic expectations of the time commitment.

I had some success porting some smaller, and some not so small programs to the new framework. I did the first few slowly and carefully. Making sure I understood all of the differences. I compiled a detailed checklist, and the other programs ported smoothly. Eventually I started on the Art program, and had some initial success. The bulk of the program was up and running. Then I hit a wall. Two problems, both related to the dynamic, in-program compile and run add-on code feature.

The Roslyn compile needs a list of dlls used by the program code being compiled. The list contains both the dlls with that I wrote and dlls that contain the .Net 6 library features that I use. In the past it was easy to find the library dlls. If I guessed wrong, then the compiler error message would tell me which type (object) I missed, and the documentation told me the dll that has the missing type. The documentation is not reliable with .net 6. Adding the dll listed in the documentation does not find the missing type. Also, VS2022 introduces two types of dlls (with identical names), one for compilation and one for execution. Grabbing the wrong one causes failure, but only some of the time.

Eventually I made a list of all dlls included with .net 6 and fed that list to the compiler. It works. Since over 90% of them are not used, I know it slows down the compile step. That slowdown is in computer time, I do not notice it. In a whole lifetime, that less than a second delay each time I compile an add-on will not add up to the time already spent trying to debug the problem. This is a good example where trying to be efficient, pick out exactly the dlls I use, turns out to be very inefficient.

Here is a test of an escape time fractal with an exotic generating formula.

Now this discussion goes deep into the weeds of programming and development tools. Feel free to skip it if you are just here for the pictures.

Often a fractal program will have a way to add new code to implement formulas and other ideas that the base program does not provide. Today's picture is an example. Typically this is done in a custom scripting language.

Such a scripting language is not as efficient as a compiled program, and does not have all the features of a full general purpose programming language. I was too lazy to invent a new language, and then have to invest in debugging and optimizing it to do the things I want to do as fast as I want it to. Especially when I was already working in a perfectly good and familiar language, C#. So, in my program the scripting or add-on language is C#.

One of the core elements of VisualStudio is the Roslyn Compiler for C# and other languages. Roslyn is also a component of the .Net framework. You can use it to compile and execute new code within a program. I can write fractal or generative art hacks in C# code, and build and run optimized code without leaving the executing program.

You may ask why bother? Since I have the source code, I could just exit, modify the source code, compile and run. Several reasons, the first is probably the loss of "momentum" going through that stop, edit, compile, run cycle. There is also reproducibility, if I save the 'recipe' for an image, and then change the core program, the recipe may produce a different image, or fail entirely. Instead, the custom code changes are saved as part of the recipe. I can create a large number of variations, without ever changing the core program, and they have a high probability of working in the future.

Next thing to verify, small variations in the basic formula and zooming.

This is not a programming blog, and I should not bore you with programming minutiae. But I have nothing else to talk about right now.

Visual Studio is the development environment. C# is the programming language I use. .Net is a framework, or a set of libraries. Visual Studio 2022 comes with C# 10, and .net 6.0.

I installed VS2022 several months ago. These tools are for the most part supposed to be backwards compatible. I could not build any of my programs, which were built on .Net 4.8. The framework was properly installed (and re-installed several times) but VS2022 could not find it, and asked me to participate in an infinite loop of un-install and reinstall the framework.

In the past, Visual Studio always provided tools to easily move your programs from the older framework to the newer version. That is not provided this time, you need to do the port manually. As there are no significant benefits to running the old framework on the new IDE, and I did not have the time to invest in learning the new framework, and the product was still in 'preview' mode, I gave up.

The next goal in the port was to make some simple changes to the coloring algorithm.

I am actually much further along on the software port than these posts would indicated. I had this one queued up to publish a month ago, and generated by the program a few weeks prior to that.

I am falling into the trap where if I do not publish something daily then it gets to be a month or more between posts.

After a couple weeks of silence, here is the start of a new series, Port 22.

A sweet red wine, a portal, a port of call? All interesting ideas, but the reality is quite mundane.

I developed the software using the Visual Studio development environment. A new version, Visual Studio 2022 has been released. I am porting my software to the new version.

This is a basic fractal image I had used as a default test in previous versions of the program. So the first goal while porting the software was to reproduce this image.

Last year I set a goal to make 150 blog posts, and I made over 300 posts. I cannot keep up that pace. This year my goal is 100 blog posts.

I am a little nervous about slowing down. I have had this web site for 25 years now. There has been many changes, and many reboots. There have been a few times when I said I was going to slow down, with the good intention of maintaining a slower pace, and then go a year or more between updates. I won't let that happen this time.

Mirror reflections at odd angles.

Here is the first of two very minimal pieces.

I completed the first one in this series some time last year. I had put together several low-resolution "sketches" as candidates for the series. I made a list of additional experiments I wanted to try. Vary the relative size of the black and color bands. Replace the rainbow with other colors, such as shades of silver and gold. Create and mix in a competing "White Rainbow". As usual, I got distracted with other things.

I am cleaning up and finishing some the better early candidates now. The additional experiments will have to wait. Perhaps I will get around to those and post a "Black Rainbow II" series in 2022.

Here is a series called black rainbow. I was experimenting with putting a black stripe between rainbow colors then twisting and distorting in various ways.

I am still cleaning up the hard drive Why? If you have not been following along, see the notes Footnotes #2 and Footnotes #3. In a way, this is a continuation of the footnotes series.

I created this one as part of the Sequence Fractals IV series, but then decided that it did not fit. I felt it had potential. I returned to it a couple of times, but I did not get anywhere.

Here is something with the hot palette from the Sequence Fractal series. Back then, I decided that it did not fit. Today, I decided it deserves a place in the footnotes series.

This is part of the Strange Zone series. Somehow I overlooked it when publishing the rest of the series.