A very short rant about school closures during the pandemic

I don’t know whether schools should be open right now.

What I do know is that remote learning is far inferior to in-person schooling, and that school is really important for kids. And that as a society, we should have tried to keep schools open at almost any cost.

Since schools were closed while restaurants and bars were open, our priorities were terribly wrong. The pandemic has involved hard choices to begin with, and decisions like this make the choice about whether to keep schools open impossible.

wasting hours because gcc’s argument parsing is crazy (or: dude, where’s my library?)

After building my new computer, I’ve been going through all of my projects on gregstoll.com and making sure they work. I try to do this periodically anyway, and moving to a new machine broke some of them.

So I’ve been working on my Pretty Pictures with Genetic Algorithms project, which uses a C++ program on the backend to generate the images. It used to use tinyjson to parse the description of the picture, but that depends on some Boost stuff which was hard to install, so I decided to change to use rapidjson which has no external dependencies. Turns out my C++ is fairly rusty, but after an hour or so I was able to fix all the compile errors!

And then I started hitting linker errors, like:

writepng.cpp:(.text.startup+0x444): undefined reference to `png_create_write_struct'
writepng.cpp:(.text.startup+0x45c): undefined reference to `png_create_info_struct'

“OK”, I thought, I know what this means! writepng.cpp calls into libpng, and I’m including the header file correctly, but for some reason I’m not linking against libpng.so. I still remember some things!

This was kind of weird, because I hadn’t actually changed anything about the png code, but it’s a new machine so anything is possible. So I make sure libpng.a is installed and seems to be in a reasonable place.

Then I made sure the linker was finding it by specifying the directory with -L – same result. (although I later noticed if the linker doesn’t find a library you specify with -l, you get a different sort of error) Now I’m pretty confused, so I add -v to get more verbose info from g++, but nothing’s particularly useful.

Right now my command line is:

g++ -v -O2 -Wall -lpng -o writepng writepng.cpp

and I’m still confused. I’m wondering whether this is a name-mangling thing – if writepng.cpp is expecting the png functions to be C-style (as it appears to, since the missing symbols are just the name of the functions), but they’re actually exported as C++ functions, then this is the sort of error you’d get. So I use readelf to look at the symbols in libpng.a and libpng.so and writepng.cpp and they’re all looking for the plain C versions.

I’m basically out of ideas at this point, so I go to bed, and the next day try first compiling the .cpp into a .o file and then passing that to g++, which doesn’t work. Now I’m reduced to some frantic searching. After another hour or so, I read a page that implies that the order of arguments to g++ matters, so I try switching around the command to:

g++ -v -O2 -Wall -o writepng writepng.cpp -lpng

(notice the -lpng moved to the end) – and it works! The reason is that apparently g++ and gcc evaluate the .cpp, .o, and -l arguments in order and get rid of any symbols that don’t seem needed at that point. So when -lpng is first, g++ reads the library, sees a bunch of exported symbols and says “huh, nothing needs these yet so I guess I’ll forget about them”, and only after looking at the .cpp argument realizes that those symbols are undefined.

I would humbly submit that this is incredibly user-hostile. People don’t expect the order of arguments to a command-line program to make a difference! I’m sure it makes the linker a tiny bit faster or whatever, but coooooooome on.

Anyway, that’s two hours I’ll never get back, although at least I did learn something…

(see all my programming rants)

Android development makes me angry sometimes

So I’m working on making an Android version of my baseball win expectancy finder, and things are going pretty well! (anyone want to beta test it??) Except…

I’m using Xamarin.Forms so I can write all my code in C#/XAML, which is neat! I was even able to add Google ads in just an hour or two thanks to this handy guide after some fighting with NuGet packages.

Then I decided to build it in Release and deploy it to my actual phone, and it started to crash on launch. The Debug version didn’t have this problem, and launching the Release build through the debugger did not give any useful information, but after some Binging and fiddling with some project settings I managed to at least see that it was crashing with an Android.Views.InflateLayoutException. Sadly there was no data in the exception or call stack or anything.

So, OK, I figured there must be something with my XAML, so I commented out everything except the main TabbedPage control, but that didn’t help. At a loss, I went back to Bing and Google (yes, pulling out the big guns!) and after looking through a bunch of links and trying a handful of random things I looked more closely at the log and saw a line like

W/resourcetype: entry identifier 0x14c is larger than 0x84

So OK, this looks bad, I guess, and after some more Bing/Googling, I stumble across a this StackOverflow question that points to this Google Groups thread with a suggestion that this is a bug in “HistoryRecord over in the framework” (?) is trying to read the theme, and there isn’t anything wrong with your code. So I try this suggested workaround of adding this to the top of styles.xml:

<style name=”Stub”></style>
<style name=”Stub1″></style>
<style name=”Stub2″></style>
<style name=”Stub3″></style>
<style name=”Stub4″></style>
<style name=”Stub5″></style>
<style name=”Stub6″></style>

These don’t do anything, they’re just there to try to work around the bug.

This didn’t work, but I figured “in for a penny, in for a pound” and added a few more, which also didn’t work. Then I changed them to the self-terminating XML tag form <style name="Stub" /> and lo and behold, the crash went away!

The kicker? That Google Groups post was from 9 years ago. This bug, which causes a crash on startup with no obvious cause and requires a basically-impossible-to-guess workaround has been around for at least 9 years.

*incoherent muttering*

Man, Javascript is still kind of dumb

I’m working on rewriting my floating point to hex converter with React. This time I thought I’d do it “right” and use all the nifty Javascript tools that everyone complains about instead of just putting a bunch of inline Javascript/JSX in an HTML file, even though that works well enough. Long term, I’d like to rewrite the marriage map with React and D3.js, so I thought this would be a good dry run.

But, maaaaan:
– I literally had to buy a React+d3.js ebook to figure out how to get all this crap set up. (the book is pretty good, by the by)
– The book recommends starting from a particular git repository. To clone that on my linux machine I had to set up some SSH key stuff, which seemed like overkill. (why do I need to do that for anonymous access?)
– To set it up, it downloads something on the order of 300 packages through npm. I wish I were exaggerating.
– Building it (even without minifying the source!) takes a solid 6 seconds on my desktop machine. This is for a ~100 line javascript file. The non-minified version is more than 2 MB of Javascript! Even the minified one is ~180K, which seems like way too much.
– React now recommends you use ES6 instead of calling React.createClass(), and there are some niceties there. But there also some stupid gotchas, like the fact that you have to call .bind(this) on every method for it to be able to access this, because Javascript is the worst.
– For some reason I’m not able to debug with Firefox’s debugging tools. (luckily Edge seems to work well)
– I wasted an hour because the new fancy fetch standard (not supported in some versions of IE so you need a polyfill) has a method called text() that returns the text of the response. Wait, no, it actually returns a promise that has the text of the response. I never realized how much I liked C#’s standard of ending asynchronous methods with “Async” before…

Anyway, I think I’m past all this crap, but I’m starting to remember why Javascript is terrible!