nilium

Agreed. I started using it back when it was a free beta and bought it once that was an option (iTunes receipt says that was a few days over two years ago), and I've probably used it daily since then. The ability to almost instantly search through tons of different docsets and find what I'm looking for, narrow them down, create groupings, and so on has made it absurdly useful to me.

I make a lot of my own docsets as well (i.e., ones for GLFW 3, Gambit Scheme, JeroMQ, and so on), since kapeli was hesitant in the past to add docsets that would be only of interest to really narrow groups of people, though it looks like the user docset thing on GitHub sort of fixes that. Either way, it not being closed off to outside docsets was nice, since I imagine it would've been easy to not allow it.

Anyway, glad to see it on HN since I'm a huge fan of Dash after using it for years. Sort of a shame it's Mac-only, since I keep looking around for ways to jump to Linux, but it looks like there're some open source alternatives. So, yeah, Dash was probably the best $30 I spent back in 2012.

Currently working on another patch to fix some newfound crashes while prepping the code for open sourcing. License headers and all that.

Plan for now is to release it under the GPL version 2 or 3 to hopefully compel people to make their modifications available (plus there's not much use for a lenient license here -- it's not a library, though some of the code could be moved to one later). This might take a day or so, so I expect this post to disappear into complete obscurity before I'm done. Might create a new HN submission for that just to let people know. At any rate, my net access is down so I have to write this on my phone, meaning any release is going to wait on my ISP to determine what's up and how to resolve the issue.

So, open source is planned, I'll just suck it up as I usually do when I release every other project of mine. Re: malware, I've decided it's not my responsibility to protect people from the malicious few. I'll let Google do that.

> Scala has slightly more overhead though from making lots of small objects

This is definitely true, though it's possible to write code that avoids it. It just ends up being slightly uglier Scala. The renderer in Ascension, for example, is all fairly bare-bones Java-like Scala because I have to be careful about how certain code is generated (i.e., prefer a while loop or tail recursion to a for comprehension or .foreach). So, it's possible to get performant code, it just ends up being more like Java usually.

In the UI code, you can get away with a little more depending on where it is. If it's inside an adapter, it pays to avoid the heavier tools Scala gives you. If it's responding to a button press, you probably don't need to worry as much. The GC will run a little more often, but the GC in Android has improved a fair bit over time.

I'll second the Java collections recommendation though — as much as I like the immutable collections provided by Scala (and I do use a few of them), they're much free-er with their allocations than Java and Android's. I haven't tried anything with actors on Android yet, though, so I can't comment on that. I just use AsyncTask as carefully as possible right now, but I really need to get familiar with an alternative to that. I'd like to try actors, plus I'd also like to get into using something like RxJava/Scala, but I haven't had anything come up where I could afford to experiment with it. Also need to see how Akka fares on Android, but same problem as RxJ/S.

It's code I've invested a lot of time in, but was never written with the idea that other people would see it, so 75% worried at how horrifying the code might be and 25% worried that someone might make a build and push a clone out with malware attached.

This actually made me aware of a bug in the last release that I just released a patch for, so that was fun. I guess nobody ever reported (or encountered? seems unlikely though) the issue until I got a crash report for it today.

Not at the moment. Still undecided on that.

I currently don't allow installation on the Galaxy Nexus because for some reason the live wallpaper has severe performance issues on Galaxy Nexus devices. I've never been able to figure out what the problem is, since it's obviously not hardware — older devices run it fine. My best guesses are that I'm doing something out of the ordinary in GL ES that I haven't noticed or that there are either driver issues (not necessarily buggy drivers) or those specific devices have something off about their GL interfaces. It's hard to say without having a device on hand for it, which I don't. I'm mostly leaning toward it being an issue with how I use GL.

Because of the issues, I decided it was better to just block the device entirely rather than have people suffer through the performance issues with the Galaxy Nexus.

Thanks! I agree on the speed, though it's kind of set in stone for the most part since that was the default when I first released the app. I'd love to go in and make a mess of the project by rewriting things and changing all the defaults, but now that I have a small amount of users, it sort of behooves me not to do what I'd do with my other personal projects.

That also makes it difficult to introduce new features since I can't just switch them on and I don't really want to pester users about it. Not entirely sure how to handle that yet, but I've been focusing on other personal projects and job hunting. Worrying about adding stuff to Ascension hasn't been a huge concern. It does what I want, so I haven't found anything else I'd like to add to it just yet.

None.