Aren't people still asking anyway, though? I swear someone did a few years ago, but I don't know exactly when and perhaps the person did it jokingly.

I don't remember anyone asking yet after we added that note to the news articles, but we started doing that a few years ago, also.

Of course, if someone happens to ask how to vote on the voting results page itself, I may have to give up then.

Quote from: TravisE on December 08, 2014, 02:08:29 pm

The site does load in https, but every link takes me back to the non-https version. Does that happen to anyone else, or is it just on my end?

Should have been fixed when I cleared all the old pretty url cached links. Could it be a chrome caching issue (if you use chrome)?

I use Firefox, but it seems to be fixed now.

Is the on-calc language available (I believe it's SysRPL, right?) viable for simple games or is it as slow as 68K BASIC?

Just adding my own experience in case anyone's curious. The built-in user-facing language is UserRPL, which I'd say is roughly on par with 68K BASIC speedwise, but often a lot faster, depending on what you're doing. SysRPL tends to work much more efficiently, especially for graphics. RPL in general tends to be “jerky”, though, because of the garbage collection method, which is a problem for games. Forcing a garbage collection each loop or few loops makes it smoother but a little slower.

As mentioned, RPL is a stack-based programming language, so the coding style takes a lot of getting used to (SysRPL, even more so), and especially debugging (though it includes an on-calc step debugger which is really helpful). Really long programs can be extremely hard to follow, but it's well suited for making lots of very small, manageable subprograms, which effectively form new “commands” in the language which you can then use to make higher-level subprograms, which can be used as commands, and so on, until you eventually create an entire large program or game out of them. (The HPs have nested directories, so having lots of separate subprograms isn't really a problem like on the TIs—and it's easy to organize custom commands/programs so they can be used in multiple projects, too.)

SysRPL is sort of a superset of UserRPL, has a number of more powerful commands, and allows you to bypass the error checking that usually happens in UserRPL. This can cause a dramatic speedup if you use it for loops that would call a lot of UserRPL words where you know that the argument types and such are correct and don't need to have every single operation recheck the arguments every time. Unlike UserRPL, though, you'll corrupt memory or crash the calculator if you mess up. It's quite easy to combine User and SysRPL code in the same project (they're both the same language internally); when I first started learning SysRPL, I just used it for the speed-critical parts and used the easier UserRPL for the rest.

There's also “HP Basic” which is UserRPL forced into a syntax of a more “normal” programming language. It's not that well documented, and I haven't messed with it much. It strikes me as being a bit of a kludge and lacking in places, and I hear it can be much slower than UserRPL.

The HP-BASIC/UserRPL compiler is of course built in as part of the OS, and there's a hidden SysRPL/ASM compiler and some hacking commands built-in, too, though you need to install a library to be able to use names for the internal commands (instead of hexadecimal addresses). A large amount of the ROM contains SysRPL code (with Saturn ASM for the low-level parts), and there are programs like Nosy that allow you to browse disassembled code right on the calc.

It can be a lot of fun for those who don't mind the “weird” programming language. The range of on-calc dev-supporting tools is just amazing.

I believe those are for when you snacked on too many SMB fire flowers at one time and may need to consult a doctor and/or the fire department.

Try the proper reset methods:

Press and hold (in order) [2nd]+[Left]+[Right]+[ON]  (clears RAM)
Remove a AAA battery; replace it while holding [(-)] and [)]  (clears RAM and archive except OS)
Finally, maybe try redownloading the operating system

If these don't help, it must be the LCD that's toast. That's a pretty strange failure mode, though.

Basically, to change a fundamental part of the Bitcoin protocol, you'd need most people to switch to it. It requires more than half the entire hashing (computing) power of the entire Bitcoin network to invalidate the current block chain and replace it with something that works a bit differently. The larger the Bitcoin network grows and the more mining that's done, the less practical this becomes. Even right now, doing that would require an insanely huge amount of resources. Otherwise, the majority of clients run by everyone will simply reject and ignore foreign blocks.

Edit: Actually, the exception to the below is when you're subclassing another class and call the parent class's method. I just realized you mentioned changing MazeApp to subclass object instead of Frame. This won't work if you are trying to extend/call Frame's methods, because they are no longer available if you're not basing the new class on it.

I don't understand exactly why you want to change it to "class MazeApp(object)", though. This is only necessary (in Python 2) when creating a parent class. Frame most likely eventually subclasses object at some point, so this is unnecessary.

Or, are you referring to trying to subclass a class called 'Object', rather than the built-in class 'object'?

Those errors can be generated when there's an attempt to call a class's methods directly, without first creating an instance and assigning it to a variable. For example, if you have a class like

class Foo(object):
    def bar(self):
        print 'blah'

Make sure you're doing something like

f = Foo()
f.bar()

and not

Foo.bar()


Pretty cool. The “half horizontal resolution” mode doesn't look bad at all.

This reminds me that the classic consoles such as the NES actually were quite limited on how many tiles could be updated per frame. They took advantage of having an extra screen-sized buffer, just as in this example (some games didn't even use that) to update rows or columns of tiles off-screen just before they scrolled into view. In this case, there is no direct hardware support for sprites; those would still need to be directly drawn, but if that can be done fast enough, this certainly does look promising, framerate wise. The biggest key here will be how many pixels can be updated per frame, and how much CPU time will be needed by AI and logic.