more project planning

I'm continuing to evaluate a possible change in direction. I'm going to be partnering up with somebody starting tomorrow which is very exciting! But it necessarily means reconsidering what I'm building. I'm also uncertain of how much I should be writing publicly about it, since now I have more than just my own efforts to screw up!

I will think about a better, more private venue to keep doing these updates. In the meantime, this blog may go dead for a bit.

project planning

Sorry for the missed update yesterday. I'm doing some project planning that isn't so easy to sum up in a blog post. I'm going on a small trip and probably won't update here again until sometime midweek.

windows buildshell fully operational

Today I got the windows version of my buildshell fully operational. It wasn't too bad, mainly because the buildshell just isn't that complicated. But of course there were still a few hangups. I'm embarrassed to admit that I spent a non-negligible amount of time getting the quotesfile working. The quotesfile is completely pointless (you get an interesting/amusing programming quote when starting the buildshell), but it makes me happy.

ubuntu mono env issues resolved (sort of)

Yesterday I found that I could no longer build and run my .net project on ubuntu, after upgrading to 16.04. On investigation this is because my mono environment was also upgraded (to a 4.xxx build). In 4.xxx versions, mono has discontinued support for .NET 3.5. That's awkward, since I'm stuck on 3.5 probably forever (a script upgrade to 4.6 still hasn't even gotten on the Unity technology roadmap).

I tried for most of the day to downgrade to mono 3.12.0. In principle this should be possible. The mono website contains a line about how to do this, which I tried and failed--I added the correct snapshot as my tracked xamarin repository, but I must have mono available in some ubuntu repo as well, because a simple install of mono-complete still added the latest version.

I also found a blog post purporting to explain how to do it. It involved pre-installing a certain set of dependencies, and then installing mono-complete with '-t' to indicate the old version. This also failed in at least two ways.

I wandered down some dark paths trying to find ways to install all the dependencies for old-mono on my machine. Eventually, I more or less gave up, removed all the mono packages, and then installed them back at the newest revision. When I idly tried rebuilding my .net project, it worked!

What seems to be happening is, even though mono 4.xxx no longer supports .net 3.5, it still ships with API stubs for backwards compatibility. Somehow I didn't get them when I did my OS upgrade from 15.10->16.04. But having reinstalled mono (several times, heh), these stubs showed up, letting me build against .NET 3.5, even though monodevelop lists this platform as "uninstalled". Running the unittests works, but it must be going against the 4.5 runtime (as that's all it has).

So I'm back in business, but I don't exactly have warm fuzzies about this. I'd really like to have cross-platform support for developing in this project, but if problems like this keep turning up, the cost may be too high.

laptop setup + xplatform build environment

The linux bug is a thing. There was already a post on the unity forms about it. That's good; I have a workaround so I can stop worrying about it for the moment.

Now I'm working on getting my new laptop set up. I've gotten Unity and subversion install and sync'd down my project. The buildshell that sets things up needs some effort to get fully xplatform, so I'm working on that now. While I worked on that this evening, I discovered that I had broken my ability to build the shared dlls in linux when I upgraded to 16.04. I am now working on straightening that out (it's broken references to the System assembly--even though the assembly exists, right where mono expected it to be).

environment setup + unity bug

In order to further test the Unity bug I saw, I upgraded my local xubuntu install from 15.10 to 16.4. I also upgraded Unity from 5.3.5 to 5.4.1f1. I was still able to reproduce the bug. However, having played around with it some more, I honed in a bit tighter on what exactly I was doing. To add the prefab into the scene, I was dragging it from the Project view, across the Scene view, and into the Hierarchy.

I think somehow when you do this, you get one copy of the prefab added via the Hierarchy, and one that gets added accidentally because of your mouse dragging over the 3d view. Now that I know about this I can work around it.

In other news, my new laptop came today. I have been using a chromebook running crouton/ubuntu as my only transportable development machine (yes, really). It worked surprisingly well for backend programming, but I didn't even consider trying to put Unity on it. My plan is to keep running xubuntu on my desktop, and run Windows 10 on the new laptop. That way I should be able to keep my cross-platform development environment truly cross-platform.

zero day

Nothing to report today. The plan is to continue sorting out whether the Unity problem I'm facing is Linux specific and whether I need to move development back to Windows. However (without any particular excuse), I didn't get anything done.

Instead of an update, please enjoy a photo-diary of the Chernobyl disaster instead.