A much better example, IMO, are these Markov generated Tumbler posts, trained with Puppet documentation and a collection of H.P. Lovecraft stories.

Well, that looks amazing. It looks like a virus capsid.

Ugh, sorry I will have to complain about SemVer again. I tried SemVer, but later dropped in favor of CalVer. CalVer is used in applications to regular users (take Photoshop and Visual Studio, for example), but I’ve been using with my library, and it works nice.

Am I on the latest version? Do I have to upgrade? Do I have the most recent security patches?

One of the reasons I dropped SemVer is that it let the user with no clue of how old their software (application or library) is. In CalVer this is explicit. It obviously doesn’t tell if the user is using the latest version, but they might recognize that the software they are using is too old.

From these three examples, you can see that semantic versioning is a very concise and structured system for versioning a release. To be fair, there’s a number of further rules in addition to what I’ve covered here. However, these are the basics.

Unfortunately, SemVer doesn’t rule only over the release step, but rule over the development too. If anyone here contribute to third-party OSSs, you might have received an answer like “I’m sorry, but I can’t make this change until next major release”. By then, many changes already happened that your patch already have a lot of conflicts with the current master branch, and even if the conflicts are resolved, your patch might not even work correctly with all the changes that happened in the master branch (example 1 of SemVer ruling over development). I stopped contributing to some OSSs, one of them being a significant OSS, because I had patches waiting for a year.

In CalVer, there’s no rule here. If you find a good way to keep the backward compatibility, good. If you don’t, you still have the choice of merging the patch and informing in the release notes that a break was made.

How do I know when to release 1.0.0? If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you’re worrying a lot about backward compatibility, you should probably already be 1.0.0.

I haven’t seen this rule applied with consistency anywhere. Some software stay in <1.0.0 forever. Others have rules like using the x.1.z as beta or alpha.

Have an open release schedule (that changes gradually)

The example used (Ubuntu) is hardly a good example for this. One table contains the past releases, and at the bottom there is the future release. Future release date is good, but shouldn’t be prioritized (example 2 of SemVer ruling over development) over getting the job done, even if it takes a longer time.

Be consistent and predictable… If your release schedule releases a new major release every twelve months, do your best to stick to it.

That’s just SemVer trying to be CalVer. And failing at it, since users will present new bugs and feature requests that will require you changing your schedule.

Communicate changes regularly and transparently What’s new What’s been fixed What’s been improved What’s been deprecated

Same rules goes to CalVer. Communication is obviously a must. But, it always looks awkward to me when there’s a major release >=2.0.0 for a software, and there’s only a single backward break. While in others there are many.

I remember when Linus was questioning (on G+) if the version of Linux should roll faster. It wasn’t a question of “is what we are currently doing correct and need change?”, it was more like “hey, what about we go faster?” And, I remember he also talked about the interval between the previous major releases and that they had already reached that same interval, indicating that maybe they should also bump the major version (another example of using SemVer as CalVer, but worse).

The version numbers were just numbers. The rules could be broken. And that’s because Linux is a kind of software that can’t be held back by the rules of a version scheme.

Ending my what sounds like a rant.

My CalVer scheme is YYYY.MM.DD.MICRO (could be using only YY for year, too). The MICRO I use for special cases, when I need to make two releases at the same day.

I’m so glad they decided to make this open source. I wonder why a custom version of wine was needed or is this just a configuration wrapper on wine to make it work easier?

It’s funny, because I googled “why women pants no pocket” to figure out why this is the case and the first result says that it’s because men who dominate the fashion industry don’t want women to have pockets.

Why don’t all the women who want pockets get together, start a company to make highly-pocketed pants, tap this unmet demand and make billions? You know, scratch your own itch and all.

My two cents regarding my personal projects…

When I was working on the MATHC 1.x.x, I was using SemVer, which has a concept of not breaking backwards compatibility while in that major version, possible of adding features in each minor version (x.MINOR.x), and having the patch version (x.x.PATCH) for fixes.

The SemVer process is very inorganic, and the development was often affected because of SemVer rules. This was the same thing I noticed when contributing on OSS projects of others. Having a critical design flaw and you just made a patch that will fix that? You will have to wait until the next major version, because it breaks backwards compatibility.

When I released MATHC 2, I switched to CalVer, and the scheme was YYYY.MM.DD.MICRO. The version was actually MATHC 2018.08.02.0. It’s a pretty straight forward scheme, as the version is just the dates. I added a MICRO for reserved use when I had to publish two versions on the same day, in case I noticed a bug right after the previous release. I always try to keep backwards compatibility, but the development of my project is not affected by it. If I have to break backward compatibility, then I will break it, and I will mention in the release notes. The versioning scheme doesn’t rule over the development process, it’s just a reflection of it. Very simple.

Regarding testing, I had test units during the first major version, but it was a lot of work for only one person to take care of, and it was hardly ever useful. I removed the test unit in the newer versions and I rely on the feedback of users to identify hidden bugs. The good thing about personal OSS projects is that you can easily make changes to prioritize your mental health over the project :)

An extreme example of unportable C is the book Mastering C Pointers: Tools for Programming Power, which was castigated recently. To be fair, that book has other flaws rather than being in a different camp, but I think that fuels some of the intensity of passion against it.

This… rather grossly undersells how much is wrong with that book. The author didn’t understand scope, for crying out loud, and never had a grasp of how C organized memory, even in the high-level handwavy “C Abstract Machine” sense the standard is written to.

There are better examples of unportable C, such as pretty much any non-trivial C program written for MS-DOS, especially the ones which did things like manually writing to video memory to get the best graphics performance. Of course, pretty much all embedded C would fit here as well, but you’ll actually be able to get and read the source of some of those MS-DOS programs.

In so doing, the committee had to converge on a computational model that would somehow encompass all targets. This turned out to be quite difficult, because there were a lot of targets out there that would be considered strange and exotic; arithmetic is not even guaranteed to be twos complement (the alternative is ones complement), word sizes might not be a power of 2, and other things.

Another example would be saturation semantics for overflow, as opposed to wraparound. DSPs use saturation semantics, so going off the top end of the scale plateaus, instead of causing a weird jagged waveform.

As for the rest, it’s a hard problem. Selectively turning off optimization for specific functions would be useful for some codebases, but aggressive optimization isn’t the only problem here: Optimization doesn’t cause your long type to suddenly be the wrong size to hold a pointer on some machines but not others. Annotating the code with machine-checked assumptions about type size, overflow behavior, and maybe other things would allow intelligent warnings about stupid code, but… well… try to get anyone to do it.

Studying X11, Xlib, xcb, xgb, XRender. Need to load all the concepts into my head.

Working on one of my personal projects, a painting software.

I’m using my own window creation framework (with Wayland, X11 and Win32 backend), but I’m not using any hardware acceleration, and not using any widget library. Instead, I’m doing 2D software rendering, with a queue with clipping rectangles for redrawing only what is necessary, and the widgets that you see on the screenshot are just array of a “component” structure, that is iterated over and rendered on the sidebar.

Currently the application is using only the main thread to render on the window, but I want to add an option to use multiple threads. So, each thread will have a clipping rectangle on the window, then these clipping rectangles owned by each thread will intersect with the rectangles in the clipping queue. The result is each thread rendering only on their own space.

Screenshot with the “brush” tool sidebar, used to configure automated generated brushes:

1. https://i.imgur.com/86mHDpF.png
2. https://i.imgur.com/FeQfOG7.png

I also run :)

Sadly it seems to happen if you make your own functions too, so it possibly happens with any case where the compiler thinks that that buffer won’t be used anymore.

I see that the article provides a solution at the end. But it seems to me a warning should be made by the compiler, instead of having to adapt all functions to prevent this from happening. Or be able to disable this specific optimization.

Amazing how fast you did this.

slightly disappointed this has nothing to do with real crustaceans

I would add that repeating yourself, in some cases, is also essential in performance critical software, not just a matter of avoiding wrong abstraction or avoiding an ugly architecture design. I’m writing a painting application (like Photoshop, Krita, GIMP), and I could use the DRY philosophy on the function to plot the brushes, but I would have a serious performance drop if I did that, because the if/else abstraction would happen in the middle of a rasterization:

void plot(...)
{
	while (row < bottom) {
		while (col < right) {
			if (plot.hardness == 100) {
				/* Use simple plot */
			} else {
				/* Use plot with smoothness */
			}
		}
	}
}

Now, imagine this with multiple parameters (hardness, roughness, density, blending, …). Instead, I copy-paste the function and rewrite with the specific algorithm inside of the nested loop.

Takes several lines of code and a lot more brainpower in many programming languages.

I completely agree with this. I often work making pipelines to process metagenomic data, which is often a lot of data with a lot of intermediate steps, all to reduce the raw data into a simple table that can be easily understood by ecologists. At first, I used to make my pipelines with Lua (great language). The script used to be ~1500L. Pretty small for programming standards, but too big for a pipeline that consisted of around 7-10 steps. Later I translated the everything that could be translated from Lua to shell script, and I ended up with a shell script <100L and a Lua script with <200L (the Lua part that I couldn’t translate to shell script).

Operations like iterating over files inside a folder is much easier in shell script, and was something that I had to do again and again on every step of that pipeline. That’s why a lot of lines were reduced.

I don’t think shell script is so intuitive, so I always kept mine small, executing existing tools or my Lua scripts. If working with shell, I think this hybrid approach prevents you from falling in this “trap”.

Bad idea, it should error or give NaN.

1/0 = 0 is mathematically sound

It’s not mathematically sound.

a/b = c should be equivalent to a = c*b

this fails with 1/0 = 0 because 1 is not equal to 0*0.

Edit: I was wrong, it is mathematically sound. You can define x/0 = f(x) any function of x at all. All the field axioms still hold because they all have preconditions that ensure you never look at the result of division by zero.

There is a subtlety because some people say (X) and others say (Y)

• (X) a/b = c should be equivalent to a = c*b when the LHS is well defined

• (Y) a/b = c should be equivalent to a = c*b when b is nonzero

If you have (X) definition in mind it becomes unsound, if you are more formal and use definition (Y) then it stays sound.

It seems like a very bad idea to make division well defined but the expected algebra rules not apply to it. This is the whole reason we leave it undefined or make it an error. There isn’t any value you can give it that makes algebra work with it.

It will not help programmers to have their programs continue on unaware of a mistake, working on with corrupt values.

Might build a game with C and SDL. Was thinking of building Asteroids, without using any sprites.

OSS stuff. Working on my math library, then I will try to work a little more on my window creation framework, before releasing it.