With lua + autohotkey scripts in windows this is definitely possible the last time I checked. You run a luascript on another keyboard mapped to a generic key, luascript inputs that as the proper text-based language
Mac, I can only assume its something you would write in applescript. But maybe you find some interesting ideas there. I found something called "http://www.orderedbytes.com/controllermate/" that might be of interest to you
You could use Karabiner[1]. No need to do the “different language” hack, just make a big pile of key remappings that only affect that particular keyboard. It’s pretty easy to target just one input device with that.
Going to court and losing, while not fun, should be instructive to the GPL community. A loss will either point out areas that need to be changed in the next GPL license version, or that a GPL-style license is not viable.
Yes, it could prove helpful to the GPL community, but it might prove harmful to the kernel community. For all intents and purposes, the Linux kernel is permanently stuck in GPLv2. If a disastrous court case somehow weakens GPLv2 and a new and improved GPLv4 which fixes that weakness comes out, the kernel will be stuck with the now weakened GPLv2.
For services that have feature parity with GV, I'd recommend ring.to. Note that ring.to is run by bandwidth.com, the same CLEC that Google Voice uses for most (all?) of its numbers, so porting is easy:
>RingTo launched over two years ago with a simple mission: help more people keep the phone numbers they love. In the spirit of moving forward, several changes are coming down the pipeline we want to share with you.
>In early 2016, RingTo will transition to a paid service and will no longer offer free accounts to new or existing users. But don’t worry, we’re making it worth your while to stay with us!
I'd say they haven't quite finished the new signup yet.
I guess this is a good thing? If it's paid it might stick around for a while longer.
No problems yet. (Knock on wood.) We never had any ambition plans of raising money or going public, so we just wanted the simplest structure that wouldn't require extra costs or overhead. There might be tax implications, but that's more the realm of my business partner, so I'm not really qualified to offer any extensive advice there beyond the fact that you'd want to consult an accountant in addition to a lawyer when incorporating.
I agree in theory. In practice, programs evolve and code gets reused. Omitting free calls because you expect the code to exit rapidly is a recipe for disaster once you change your mind later. It's much easier to put this stuff in from the start than it is to retrofit it later.
> That's acceptable for a command-line program that will terminate quickly
No, it isn't; you don't know how quickly the program will terminate, in general, and it only takes one program running longer than you expect to eat a horrible amount of RAM.
I'll make a stand for it being bad style to free() memory when in any reasonable run of the program exit() would free just as effectively. This is simply arena allocation; some very excellent, well-regarded C code uses arenas and pools in the same idiom.
The downside to calling free(), apart from performance (malloc/free are extremely expensive), is that messing them up creates bugs that are much worse than simply holding on to some allocator metadata until the program hits exit().
The upside to calling free() is that it is a valuable lesson in understanding memory lifetimes for a beginner programmer. You can't know when it's good to omit free until you know what it means.
Messing them up exposes bugs that are likely to bite you in other ways. If you can't get malloc()/free() right, you don't really 'get' the flow control/data flow through your program yet and that is a problem.
Arena allocation is inherently simpler and less error-prone than demand-allocating and demand-freeing. It's not valid to say that arena allocation is "hiding" bugs; what it's doing is foreclosing on the possibility of having those bugs.
Virtually no large project has ever gotten malloc/free completely right in its first revision; for the past 20 years or so, most projects get this wrong to the tune of "remote code execution".
Not in general, no, but this particular program doesn't allocate a serious amount of memory (think `ls | less`) and doesn't contain any system calls which can reasonably block[1], so it's extremely unlikely to bite you in this case.
(I do think it's bad style, and would never write this program this way.)
[1] Assuming you stay away from the Zombie^W Network File System. But NFS mounts going away is bad news anyway, this program holding an extra KB of swappable memory doesn't really intensify the pain.
