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.

I admit to doing the same thing with the Super Mario live wallpaper, and with a Droid 1. It ruined my battery, but it was worth it. I remember being able to turn on some switch that'd get it to display the path it was taking through a level, which was really cool to me. I miss that live wallpaper — the Droid less so (even though it's sitting on my desk because it's the only thing I have running Android 2.x).

Besides that, my argument is that if a you spend a lot of time in your launcher, it might affect battery life in a somewhat noticeable way. Typical usage should have you in another app most of the time, but that's speculation on my part. I could imagine folks using their launchers a whole lot if they were packed with widgets that did more than just display things, but I've never had a lot of luck finding widgets I liked. Ultimately, if you or anyone else is concerned about squeezing every possible minute out of your battery, your best bet might be to have a solid black static wallpaper. Mostly comes down to priorities.

Edit: http://android.ccpcreations.com/mariolive ⇐ I think that might be the same live wallpaper from back then? Can't verify it right now, and I'm wary of installing foreign APKs these days, so exercise caution.

The only thing I can imagine would be relevant is that I'm using pfn's android-sdk-plugin.[1] I also have a sort of generic build.scala file I tend to reuse for Android projects (it's based partly on Ascension's, but has been tweaked a bit), which may also be useful.[2] I leave most of the proguard configuration up to pfn's sbt plugin since it does an acceptable job, but your mileage may vary.

[1]: https://github.com/pfn/android-sdk-plugin/

[2]: https://gist.github.com/nilium/db5bfac2174370ebdd97

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.

It'll compile to JVM bytecode. I believe it also compiles to Javascript (I'm not sure if this is still considered experimental — I haven't looked in a while), which is pretty cool. I think it used to also target the .NET CLI as an experiment, but I'm pretty sure that's no longer a goal.

The important thing for me was that it compiles to JVM bytecode that's compatible with Java 1.6, so the resulting code can all be converted to Dalvik fairly quickly. The main downside right now is that you have to heavily prune the Scala stdlib, since it's packed with tons of methods and dex has a 16-bit method limit[1] — and you will hit it if you don't prune it (using proguard or another tool of your choice).

[1]: https://code.google.com/p/android/issues/detail?id=7147#c6

None.

That depends on whether the person pronounces it as an alphabetism or as a word. Some people say FAQ and pronounce each letter (like /ɛf e kyu/¹), in which case they use "an". If they pronounce it more like a word (like /fæk/) then they'd use "a". So, it's a difference that depends on how the person speaks, and may be right or wrong depending on how each person learns to pronounce the acronym.

[1]: My IPA is rusty, so bear with me.

Chill out, manbrodude. Just learn from your mistake. It's not like you're being crucified, just being called out for perpetuating something stupid and being misinformed. If you're concerned about your appearance, maybe pull the post, but a better thing to spend your time on would be learning how to use Obj-C so you don't write terrible code like the Xamarin folks. Live and learn, as it were.

The problem people have with this is not that you're complaining about Obj-C's verbosity -- this is a well-known complaint and something anyone using it will probably agree with. The problem is that you've just displayed a fundamental lack of understanding of 1) the difference between Obj-C and Cocoa (seems the Xamarin folks are just as guilty here, which is odd), 2) the difference between Obj-C and C, and 3) the difference between Cocoa, Core Foundation, and other frameworks. In reality, only one of your examples is Objective-C while the rest are C, and you didn't even handle the Objective-C or C cases as well as you could have, so it does make you look like an idiot. Either way, you learn from it and the 'net will forget you within an hour, so it's not a huge issue.

I have to admit, most of these seem like the author has little understanding of Cocoa or Objective-C. The first example is fairly verbose, though that's pretty typical of Cocoa in some cases. The second example is just plain strange considering one could just as easily do "NSDictionary *dict = @{ key: value, ... };" (which is backwards since it's just syntactic sugar for another method of creating an immutable dictionary) and spare themselves the direct use of Core Foundation types. The third example isn't even Obj-C and more or less cements my opinion that the author hasn't got a clue what he or she is talking about.

So, overall, this just comes across as hyperbolic and silly. It's cute and I'm sure the author felt smart by making this an image (why is it an image?), but it's mostly devoid of substance.

I remember something similar, though the real cause of my time on the computer ending was because I was on dialup and that would tie up the phone line. This was back when I was much younger and with my parents, but after my family moved all of our phones off the landline and to cellular, we ended up getting a lot more use out of the computer. After all, the computer only had entertainment purposes if you had a movie or a game, and all our games were the single player sort. So, with the advent of the Internet, there were things to do on the computer to pass the time, like browse webrings and forums or try and fail to learn Esperanto (and RPG Maker 95, which probably contributed a lot to my interest in game development).

Before all that, I spent a lot of time climbing trees and wanting to be an architect and writer (the latter of which I've been pursuing for a while now). My brother and I'd drag planks into trees and we'd build little things we called forts and make up our own currencies (using the tabs on soda cans, for example), we'd play with our family's chickens and cats, and we'd grouse about picking up fallen apples (because it was boring) and so on. Odd to think how little of any of that I'd get away with now -- now I'd suffer some odd looks from folks for climbing a tree that looked especially climbable. Really, the computer was just for Doom and Encarta and writing book reports. That's just rambling though and not all that interesting or indicative of any change other than growing up a bit.

Unfortunately, I was a child back then, so my memory of pre-Internet computer use is probably different than that of someone who was an adult the entire way through. Would be nice to see a bunch of people writing about it - not so much about how computers and the 'net changed things, but what they were like beforehand without concerning themselves too much with the difference between now and then.

To kick this off with my own plans, which are fairly simple, I aim to release all software I cease selling and developing (assuming I do both) as open source. Likely under licenses of varying permissiveness. I figure some might contain code I consider very useful and I'd want to see used elsewhere, but others I might feel better about licensing under something like the GPL 2 or 3 for learning purposes.

It's not a hard and fast plan since it depends on what I'm aiming to do with any given source code. That said, I would prefer the source code and resources necessary to work with said code were available to everyone, especially users who might feel like they completely lost something post-mortem, after a project is effectively dead.

Their FAQ explains there is a mildly cheaper upgrade path for people who already purchased v1.0:

> The final release will sell for $69.99, with an upgrade available to registered users of Kaleidoscope 1 for $49.99

So, save $20. Not terrible. My gripe right now is that to save the most money, I have to pay for software that is incomplete and I have no promises about what will happen if it never makes it out of beta. Granted it seems likely they'll finish it, but not knowing their plans for failure bothers me.

I don't think sticking with GTK for the OS X version is a wise idea. It really just needs to go Cocoa or not bother, since right now it's downright unpleasant to use for me. Scrolling through text using a trackpad, for example, feels completely unnatural next to the rest of the OS X UI (horizontal scrolling appears to barely work at all - vertical scrolling isn't too bad but there is something very off about it). I think the decision to go with GTK for the OS X version was just a poor choice and probably not one made by anyone who uses OS X often.

In the meantime, I guess I'll go look at the source and see what kind of changes would need to be made to use Cocoa in place of GTK on OS X.

> Arguments against helping in ways that have specific impact (providing food, assisting with relocation, etc) are a straw man. It's not better to do nothing than something of small value.

My argument isn't to do nothing - again, this looks like a nice gesture - but that you should do more. Maybe take all your earnings for a month and donate them to help the victims. You can evidently afford to give out almost-free accounts, can you do anything better?

> I have plenty of photo albums in my closet and if those somehow got lost or destroyed then I'd be devastated (more than any other physical object in my house).

Then scan them and throw them on Dropbox. Your service actively costs the victims money, Dropbox does not, so which helps more?

> Really? If we get more feedback like that then we're happy to change or give refunds. We're set up for subscriptions so it's the easiest way to do address verification. If a penny a year is too much, we'll gladly fix it.

These are people who are already financially strained by the hurricane. They may not even have a penny anymore. Did you consider this?

This seems like an iffy marketing thing to do to try to advertise and get users. Why not detail what else you've done to help those whose lives were upended by the hurricane? Why does your business have to come into it at all? Did you do anything other than decide to arbitrarily give not-really-free accounts to people when that won't help them rebuild afterward? (If you're still charging them $.01 a year, that's still charging them something. You ought to fix that.)

Either way, looks like a nice gesture, but one that's ultimately meaningless since I doubt a lot of the victims care about your service. It's rather useless compared to actual help.

Oddly enough, this is probably the only reasonable response. Of course, you don't get clicks by saying, "let's wait and see." You have to go out, pants off, hopping on a table and shouting, "Windows 8 can't win!" So, that's what people will write.

With Windows 8, I think we'll probably see more mild annoyance as folks buy new PCs for their homes. After two weeks, they'll likely get used to it, then we'll never hear another word about Windows 8 failing. I just don't see the change being so enormous that users will really care long enough to affect anything.

It'll probably be like Vista: a lot of people dislike it without using it, some dislike it for a specific reason (like drivers), and most get along with it just fine and don't really have any problems. The UI changes are enough to probably increase the size of the group complaining, especially the group that hasn't used it, but I don't think it's enough to stop Windows 8 from succeeding in the long run.

Oh, I'm aware, it's just strange to see his name as anything other than "Tim Cook." One would think exceptions should be made to style guidelines to ensure the reader doesn't pause and think, "that's just weird." Strict adherence to style guidelines doesn't always produce the best results.

I like Apple's response, but I don't think we need to be reminded of it with every new article repeating their message (or in this case, not even bothering to share the message). It was nice seeing the link to Apple's site here the first time. The TechCrunch link didn't really contribute anything, though that's typical of TechCrunch. Far as I can tell, the only thing the NYT does here is summarize what led up to it and relate it to MobileMe and so on.

They also refer to Tim Cook as "Timothy D. Cook, Apple’s chief executive," which honestly baffles me for some reason. I suppose it's just strange seeing an article not refer to him as just Tim Cook (which is what everyone else would use, including Apple). They also seem unable to spell "iPhone" correctly when it begins an article.

At any rate, I think the Apple's own page is sufficient unless something unique is added, and I just don't get the impression that the NYT is doing that. If anything, they're actually ignoring aspects of the message: there's no mention of the alternatives Apple suggested, including Bing. I personally found that interesting, and to ignore it seems a little strange.