Jump to content

  • Log In with Google      Sign In   
  • Create Account

The Bag of Holding



VISUAL STUDIO IS A SELFISH WANKER

Posted by , 30 June 2014 - - - - - - · 741 views
Angry Apoch
Why in the ever living FUCK does Visual Studio 2012 insist on bringing itself to the foreground every time the debugger starts?

This is fucking horseshit. I have multiple projects that I have to work on concurrently, each with a separate VS instance. So if I want to fire up one instance's debugger, and then start investigating the effects in a second instance's debugger, THE FIRST LITTLE FUCKER STEALS FOCUS FROM THE SECOND INSTANCE AND STARTS FLASHING ALL OVER THE TASK BAR LIKE "OH LOOK AT ME I'M SO GODDAMN IMPORTANT THAT IF YOU DON'T LET ME TAKE THE FOREGROUND I'LL PEE ON YOUR SHOES."

I cannot find a way to disable this, which makes it Yet Another stupid behavior that Microsoft insists on shitting into my dinner plate. For whatever mind-bogglingly asinine reason, someone was enough of a FUCKING MORON to think that stealing foreground focus is an acceptable thing to do.

Let me simplify the problem for you, Anonymous Microsoftie Who Does Dumb Shit: TAKING FOREGROUND FOCUS IS WORSE THAN HITLER.

That's fucking right, I said it. Worse. Than. Hitler.

Maybe not as bad as the unholy love child of Stalin and Pol Pot, but definitely fucking worse than Hitler.


Barfing out some thoughts

Posted by , 19 June 2014 - - - - - - · 485 views

It's an interesting time, that's for sure.

Work has been consuming a monumental portion of my time and energy lately; and while I can't talk about it yet, I can say that it has definitively been a lot of fun and I really can't wait to unleash what I've been working on. There's a ton of potential in it and it'll be endlessly entertaining to see how people react to the whole thing.

Outside of work, I've been pursuing a few various hobbies a little more than I have in the past. This loosely includes doing a bit more gaming than I have been recently, which is a nice change. My PS4 still sits unused until some actually good games come out for it, but until such time as I have a meaningful purpose for that console, I'm getting a ton of mileage out of replaying (or finishing) games on the 360 that have been gathering dust.

On top of this, I'm working on buying my second house, which isn't really a giant ostentatious display of ludicrous wealth... more a function of not having had a chance to sell the first one yet. Either way, buying and selling homes is a pretty exhausting affair all around, and a significant number of my already-limited spare brain cycles have been stolen by that entire mess.

All that is really just background. I'm not really interested in bitching about how busy I am or whatever; my point is that there's not enough hours in the day to do all the things I wish I could do.

Speaking of things I wish I could do... Epoch has been suffering because of all this other stuff. I still have a massive list of things I want to do with both the language itself and the surrounding tooling... there simply isn't enough clock to go around.

Yes, the language self-hosts now; yes, the compiler supports almost everything it needs to in this revision of the language; yes, the IDE is slowly shaping up into something actually worth using. But there's so far to go, and my priorities have simply been elsewhere.

Some of my shift of focus is actually due in large part to Apple's recently-announced Swift language. I have very mixed feelings about Swift. A careful observer might notice that there are some conspicuous similarities between Epoch and Swift; this is, I assure you, completely coincidental.

What is not coincidental is that someone noticed those similarities about a year ago - long before even the idea of Swift was public knowledge. The story really isn't all that long or complex or interesting, but the bottom line is that I nearly wound up working for Apple on their compiler and IDE tools. It was a very, very close thing, and in the end I made the exceedingly difficult decision to decline the opportunity, for mostly personal reasons.

The point of all this is that seeing Swift announced - and delivering many of the very concepts that I've talked about building into Epoch's core language and tools over the years - is kind of difficult for me. To be perfectly clear, nobody appropriated anything from me or Epoch without my knowledge and/or consent. The fact that Epoch and Swift have such startlingly parallel goals is why that opportunity happened, not because of it.

On the one hand, Swift gives me a lot of validation. They've observed the same weaknesses and pain points in contemporary languages as I have, and settled on many of the same approaches to alleviating those problems. There's a lot of things in the language and tools that I wouldn't have done, but that's kind of like saying one painter used a different hue and brush stroke to paint his sky than some other dude did... completely meaningless and kind of obvious. Different creators will wind up producing different creations.

The flip side is that Swift means Epoch will forever be seen as the copycat, not the originator of some of the core ideas that I've been pushing for so long. In the end nobody cares who had the idea - they care who popularized the idea. And Apple has without question pushed a lot of my personal grievances directly into the spotlight, and offered up great solutions to them. I don't regret the choice I made, but it is kind of sad that I didn't get to be a part of doing that.

In a way I feel like Epoch no longer has a chance to be judged on its own merits, although I know that's not really true. It's more of a feeling of having let myself down a bit. When I first envisioned Epoch over eight years ago, I genuinely wanted it to be a major game-changer in the programming languages space. Between Go, Rust, and Swift, many of the key points of the first language proposal have been addressed.

To be sure, there's still room for the unique blend of ideas that Epoch has become, and I still feel that Epoch can be a better solution to certain classes of problem. If nothing else, it will certainly continue to be the language I'd like to program in whenever possible.

"Getting awful crowded in my sky."


The Five Stages of Programming

Posted by , 09 June 2014 - - - - - - · 1,060 views

All programmers undergo a transformation, from the moment they first start typing code, until the moment they realize that there's more important things in life than making computers obey one's whims. (I hypothesize that this latter moment occurs after death, because I sure can't think of anything more important!)

As with all people doing jobs that involve rigorous mental discipline, programmers love to create models of things. I therefore present to you, the Five Stages of Programming, a descriptive model for how one is likely to evolve through the course of a programming career.


Denial
Initially, the programmer begins overwhelmed by the magnitude of the craft. There are many things that are obviously possible, because other programmers have done them; but the neophyte is as yet unable to imagine how they are done. This leads to the creation of a fabricated reality, wherein the beginner builds a theory of how complex programs - as yet out of his reach - might be made. Since the programmer presently exists in a state of rejecting reality in preference to his own imaginary construct, this is referred to as denial.

Anger
As the programmer's skills progress, he begins tackling more and more complex problems, working his way into ever more sophisticated software. At this point, he knows his limits and accepts them more fully than during the Denial phase. Unfortunately, this frustrates the programmer intensely. Most programmers in this phase can be heard uttering streams of truly hideous profanity while bashing their keyboards to pieces with a stapler. Clinically, this is known as anger.

Bargaining
This phase occurs after a brief but intense epiphany strikes the programmer. It is clear already that programming can be frustrating due to the limitations of the programmer's skill set; but what becomes clear after the moment of revelation is that the computer is, in fact, a mentally unstable demon machine bent on destroying the programmer's world. In order to defeat this demon and ship working software, the programmer must resort to bargaining.

Depression
A second epiphany occurs: the computer is not, in fact, a mentally unstable demon machine; the insanity belongs solely to the programmer. Confronted with the utter futility of his attempts to understand and reason about reality, the programmer breaks down and enters a prolonged funk. Apathy is the most common manifestation of this phase. Regardless of the outward symptoms, the programmer will spend a truly tragic amount of time in the depths of depression.

Acceptance
Only a few programmers reach this final phase, wherein the burdens of broken builds and memories of garbled call stacks fall gently away, and profound inner peace is achieved. When the programmer realizes that he's better off flipping burgers than bits, he has at last overcome his misguided obsession with controlling digital machinery, and achieved acceptance.

Tragically, most programmers die before they come to terms with the inherent absurdity of their occupation.


Now if you'll excuse me, I have some code to write.


VS2012 SUCKS AND I CAN PROVE IT

Posted by , 06 May 2014 - - - - - - · 1,054 views

I am thoroughly PISSED THE HELL OFF right now.


One of my favorite text editor options in old versions of Visual Studio was "Go to selection anchor after pressing escape." If you never experienced the blissful joy of this, here's what it did:

- Open some long code file
- Hold Shift
- Accidentally press PGUP instead of HOME, or PGDN instead of END
- Oh shit! Now my selection is all fucked and I lost my editing position!
- But wait, all we have to do is press ESC and we're right back where we were, like nothing happened!


This is FUCKING BEAUTIFUL for someone who types fast and makes a lot of mistakes with hitting keys (like me) due to using a lot of different keyboards during the course of a given work week.


SOME STUPID BRAINLESS FUCK HOLE AT MICROSOFT EXCISED THIS FEATURE FROM VS2010 AND IT HAS NOT COME BACK.


I didn't realize how much I missed it until I made the same mistake four times in a row today. In a fit of anger I started looking for ways to force the option to activate.

Here's the fucking stupid part. Look in the Visual Studio infrastructure documentation for a property called GoToAnchorAfterEscape. This property EXISTS in 2012 and is DOCUMENTED. (For the irony of this, look up the docs on Google or whatever. I'll wait.)


Want to know something even more fucking retarded?

If you modify your .vssettings file to set this to True, or try and import another .vssettings file with this property set to True, or generally make any attempt whatsoever to set this to True, VISUAL STUDIO FUCKING ERASES YOUR SETTINGS ENTIRELY. Doesn't error, doesn't quietly fail, IT FUCKING DESTROYS ALL OF YOUR PREFERENCES.


Considering I live near Redmond, some stupid FUCK needs to watch his back for a while, because I swear to every deity ever invented that if I find out who made this decision I will feed him his own fucking testicles.


Why YOU should embed a web server in your game engine

Posted by , 30 March 2014 - - - - - - · 5,187 views
user testing, playtesting and 2 more...
I'm going to give you a sales pitch. It might sound outlandish at first, but bear with me - I think, by the end, you'll agree that this is a Good Thing™.

You should embed a tiny web server in your game engine.


It doesn't need to ship with the game, of course; this is a development tool. If you're into letting people mod your work, though, consider leaving the server active.

Don't roll your own. That takes too much work and is a security liability. There are plenty of tiny HTTP servers available in the open source world, in virtually any relevant language you can name; pick one and go with it.

What does this server do, you ask? Simple. It provides a window into the game world that can rival even the best IDE debugger's offerings. It gives designers and content creators a way to iterate on their work almost instantly instead of spending hours in the build/test/tweak/rebuild cycle. And it offers a mechanism for directly manipulating your game state for easy experimentation and exploration.

Sound fantastical? Too good to be true? Read on!


Debugging Unhinged
Ever wanted to dump a list of every NPC in your game and view its current state? Done. Stuck on a bug that only repros after several hours of play on someone else's machine, who doesn't have a debugger installed? No problem! Just dump the relevant data through your web server and you can diagnose it right at their desk. Frustrated by the difficulty of reading complex data structures in your debugger's interface? Worry no more; you can output the data you want and view it in any way that makes sense to you. No messing with visualizers or other IDE extensions.


The Ultimate Iteration Tool
This was actually my original motivation for building one of these suckers. Suppose you're working on tuning a game feature, and you need to edit a few numbers repeatedly. Make a tweak, test the changes, tweak some more, rinse, repeat. If you have to run through a build cycle every time this tweaking happens, you're in for a lot of pain.

Worse, you will lose context every time you wait on a build. Even if all you need to do is restart the engine or reload a level, your brain will stop processing the task at hand and get distracted a tiny bit (or a lot). If you could edit those numbers and instantly see the game change in response, you can keep that feedback loop tight and fast.

The best part? Iterating instantly means you'll not only have time to try a lot of ideas, but you'll find that over time it changes the kinds of ideas you have in the first place.

This is powerful.


OK, OK, sign me up. How do I do it?
Pick some lightweight HTTP server code. Plunk it into your engine and set it up to listen on some innocuous port (I like 8088). You're going to need to implement three things: the landing page, the "features", and the web-facing UI.

First, the landing page. This should just be a list of things you can go do in the game. As you add features, it should grow. (Hint: generate this page dynamically. Trust me, it's cooler that way.) This is the first thing a user sees when hitting your web page, and should help guide them into what they want to see or do.

Secondly, the features. This is the bulk of the work. In my system, I have a simple central API where I can register a "web console feature." This is basically just a set of callbacks. When someone opens the web page for the game, they click a link for a feature, and the appropriate callback is invoked.

Each feature is just a well-defined unit of functionality, such as "list all NPCs" or "drill into detail on a specific NPC" or "show me the stats of all the weapons in the game" or whatever. From the code side, the implementation is easy enough, but once you start wiring this up, chances are you'll get addicted to it and find yourself wiring up more and more code to the system.

Now for the UI bit, and the secret sauce. Don't generate HTML in your web server. Instead, generate XML documents. This allows you to keep the code that emits the web page constant, as long as the data it puts out remains in the same form. When you want to actually use this XML, then you write a simple XSLT layer that turns it into something pretty.

This last bit of separation is crucial. It means you can update your view of the game data without rebuilding any engine code. It also means that you can have a web dev or someone else comfortable with XSLT and HTML build the UI for you. You can even do fancy JavaScript, CSS, and whatever else your browser supports. Just remember to keep the original data in simple XML, so that the UI layer can be upgraded at any time, without touching the engine itself. This is especially vital on larger teams where you don't want to constantly make updates to the "NPC code file" every time you change the color scheme of the UI.


Bonus Mode
Here's a handful of ideas to run with, that make this system really shine:
  • Give each game object a unique ID. Offer a URL that lets you enter an ID and see details about the corresponding game object.
  • Attach state information as well as static information. Don't just say this NPC has 50 hit points, show his max as well. Hell, show his entire character sheet or whatever.
  • Don't forget this doesn't have to be read-only. Letting people edit the game via the web console is insanely powerful and a great time-saver.
  • Mock up a rough draft and hand it to a Web UX designer to build a really shiny product out of it.
  • Try to make URLs stable and easy to share between developers.
Do all this stuff, and I promise your team will love you. YOU might even love you, I don't know. Either way... enjoy your new fame and glory!


More diversion

Posted by , 28 January 2014 - - - - - - · 907 views
JavaScript, IRC, bot
I got tired of having my IRC bot be a plugin to a Chrome plugin, so I started tearing apart the CIRC Chrome extension and stripping it down to serve as a bot hosting platform. The UI already has some tweaks to support bot features, and having direct access to the whole Chrome extension API is very liberating.

On the downside, it's chewing up an increasingly large amount of my free time, and taking away valuable energy from other projects (*cough* Epoch *cough*). But I sort of needed the distraction for a while, and now it's just too much fun to quit without a decent project to show for all of it.


Of course no IRC bot is complete without the ability to converse, so I started writing up a simple order-2 Markov chain sentence generator. These are pretty bog standard in the language generation world for low-fidelity conversation.

The big trick with Markov chains is training data. An order-2 chain requires a pretty substantial amount of English to inspect before it starts sounding even vaguely sensible. Most of the output is just direct quotes from what it was fed, since it doesn't have enough contextual information to "understand" how to rearrange phrases and sentences yet.

I'm currently at something like 75KB of JSON representing the internal state of the Markov chain system, and it still sounds pretty idiotic. I'm confident based on past experiments that it can be improved quite a bit - the only factor is how much data I can feed it.

I'm secretly having it listen to IRC channels and selecting the longer and more lucid-looking sentences to add to the training repository. This should be a fun way to add some flavor to the bot.


If I decide to continue hacking on this, I'll probably start by cleaning up the rest of the CIRC code I... erm... borrowed. Once that's done, I'm considering posting a copy of the extension code on my scribblings site for other intrepid Chrome users to futz with.

As a stretch goal, I kind of want to write a Bayesian classifier to try and get a bit of a stimulus/response thing going, but that's a ways down the road in all probability.


And now for a brief diversion

Posted by , 26 January 2014 - - - - - - · 778 views
JavaScript, IRC, bot
So I got bored last summer, and started writing an IRC bot in JavaScript.

This weekend I got bored again, and polished it up and posted it on my scribblings site. You can view the entire beast here.

Note that I make no claim whatsoever to have written "good" JavaScript code.


Epoch IDE screenshot

Posted by , 15 January 2014 - - - - - - · 1,604 views
Epoch, Era
Just wanted to share some of the recent progress on the Era IDE:

Attached Image

There's a lot of stuff going on under the hood here, and not much in the way of outwardly visible changes, but it's still moving forward at a decent rate and I'm pretty happy with where things stand.

I can almost tolerate working in Era instead of Notepad now! Won't take too many more bits of polish to get it to be a total win.


Carpentry and Magic Resizing Logs

Posted by , 14 January 2014 - - - - - - · 989 views

Once, there was a carpenter.

He was a pretty good carpenter, too, and knew a lot about his trade. He made a decent living selling his wares in the local market.

As the carpenter wandered through the forest looking for good trees to use for his next project, he stubbed his toe on a small lamp. He picked up the lamp and examined it closely. While trying to ascertain the origins of the lamp, he was surprised to see it begin to glow and shimmer. Presently, a genie burst forth.

The two contemplated each other in silence for a moment. At long last, the genie spoke.

"I see that you are a skilled worker of wood. I will reward you by granting a single wish."

The carpenter pondered for a moment, and then brightened up - he knew exactly what to wish for.

"You know the old rule, measure twice, cut once? I wish that I could break that rule. I want to be able to cut as many times as I need to until I get things perfect - even if it means making the wood longer instead of shorter!"

A mischievious glint appeared in the genie's eyes as he intoned, "Your wish is granted."

With that, the lamp shattered into a thousand pieces, the genie disappeared, and the carpenter went about his business. Within a few hours he was so consumed with his work that he completely forgot about the encounter with the genie, and his wish.

Days later, as he was feverishly working on a difficult bit of cabinetry for a local aristocrat, he mistakenly chopped an extra inch off of a plank. Overwhelmed by despair, he sat down, holding the ruined wood in his hands, and fought back tears - it was the last piece of wood that matched the cabinets, and without that piece intact, he would have to start over in order to ensure everything was of the demanded quality.

As he sat in frustrated silence, he suddenly recalled the genie, and his wish. With a deft snap of his fingers and a gentle tap on the plank, the carpenter magically restored the wood to its unmarred state.

Overjoyed, he returned to work, and soon had delivered the best cabinetry ever seen by the townsfolk.

Over the next few years, the carpenter grew ever more reliant on his ability to un-cut his work. Soon enough, he stopped measuring things altogether, and simply slapped together random chunks of wood at a whim. If they didn't suit his fancy, he'd pick a few bits to chop off and try again.

Meanwhile, word of his productivity and skill had spread far and wide. Eventually, a visitor arrived from a distant kingdom, and asked to see the famous carpenter and his majestic constructs.

The visitor walked into the woodshop and started to look around. Everywhere he saw chaos: haphazard blobs of shapeless mess that only barely resembled chairs, or tables, or whatever else. Stunned, he asked his guide quietly if he was in the right place - surely the world-renowned carpenter made better things than this!?

Despite his attempts at tact, however, the visitor was overheard by the busy carpenter, who emerged from a pile of sawdust and shavings to confront his guest.

"Of course I'm the world-famous carpenter! Don't mind all this stuff, this is just work in progress. After all, many of my customers don't even know what they want until after I make it for them! So I just make a version, and they tell me what to change, and we repeat this every two weeks until we're both happy. It's a great process."

The visitor walked away and returned to his homeland, saddened that he had gone so far to see a master craftsman, and instead had discovered someone not even worthy of an apprenticeship in his native kingdom.



Of course, none of this has anything to do with woodworking, genies, or distant kingdoms.

Automated refactoring tools have made us lazy and unthinking, and agile methodologies have worked hand in hand with such tools to encourage us to develop software this way. Don't try to use your brain! Don't think ahead! Never talk to your customer beforehand to come to an agreement! Just blindly surge forwards, cobbling together whatever dreck it takes to make it through the sprint, and then "fix it" later!

Genies may sound nice, but of course they are always devious and our "granted" wishes always turn out a little less awesome than we imagined. The carpenter got his automated refactoring tools, yes, but he also lost the respect of his fellow craftsmen - who may well have been amazed by his abilities if he had used them judiciously.

So just remember: if refactoring tools are saving you a nontrivial amount of time and mental effort on a daily basis, the genie is having the last laugh.


{Re}birth of an IDE

Posted by , 11 January 2014 - - - - - - · 758 views
Epoch
Tonight witnessed the first fully operational build of the Era IDE compiled under the end-to-end Epoch toolchain.

This is cool for a number of reasons: it means that the Epoch compiler can build Windows .EXEs with embedded resources correctly; it means that the entire language toolset is now self-sustaining; and it means that I can finally get back to working on making the IDE better.

First goal is to take advantage of the new compiler's ability to do separate compilation, and clean up the existing Era implementation so it no longer lives in a single monolithic file. Second goal is to get project support roughed in so I can start editing multi-source-file projects from within Era itself.

Once that's all in place, it'll be time to remove the old C++ parser that does syntax highlighting in Era now, and replace it with one that's written in Epoch - ideally lifted directly from the actual compiler's parser so I don't have a ton of stuff to update every time I tweak the language specification a bit.

After that... I'm not sure. I might package a release, I don't know yet. There's a lot of cleanup work to be done on things so I'm not terribly excited about publishing a release with code in its current state. On the other hand, I've landed several major milestones here and it'd be a shame not to commemorate that in some fashion.

Eh. I'll figure that out later.



For now, back to hacking on the IDE!






September 2016 »

S M T W T F S
    123
45678910
11121314151617
18192021222324
2526272829 30  


PARTNERS