The latest trunk of libevent now has pkgconfig support due to a quick patch I sent along earlier today.
Oooh, the majesty.
Thursday, April 16, 2009
httperf update April 16, 2009
I have been accused of ignoring the fate of httperf recently. hmmm. Well, fair enough, it's certainly been a while since I committed anything to the repository.
That said, httperf has hardly left my thoughts.
I am pretty familiar with the tool at this point, and to be quite honest I am more than a little bit frustrated with it's design. Take a look for yourself! It's got a quite a few weird design concepts built into it, include c-ized objects (come now...), an Any type (oh good), it's own event loop implementation, it's own timer implementation (which at least doesn't leak memory since I re-wrote it) and it's own http implementation. It seems to come from an era before the advent of code re-use... (No offense to David Mosberger)
That said, it does implement the workload generator aspect of it's design quite elegantly. Differentiating between sessions, connections and requests is quite a useful as well.
Anyways, I have been busy recently ripping the guts out of httperf to the point where it is hardly recognizable any more.
The event loop, timer and http implementations are going away javascript:void(0)in lieu of those built into libevent. The core of httperf and the stats collection are moving to their own shared libraries, and the workload generators are each moving to distinct binary files.
Sound good?
That said, httperf has hardly left my thoughts.
I am pretty familiar with the tool at this point, and to be quite honest I am more than a little bit frustrated with it's design. Take a look for yourself! It's got a quite a few weird design concepts built into it, include c-ized objects (come now...), an Any type (oh good), it's own event loop implementation, it's own timer implementation (which at least doesn't leak memory since I re-wrote it) and it's own http implementation. It seems to come from an era before the advent of code re-use... (No offense to David Mosberger)
That said, it does implement the workload generator aspect of it's design quite elegantly. Differentiating between sessions, connections and requests is quite a useful as well.
Anyways, I have been busy recently ripping the guts out of httperf to the point where it is hardly recognizable any more.
The event loop, timer and http implementations are going away javascript:void(0)in lieu of those built into libevent. The core of httperf and the stats collection are moving to their own shared libraries, and the workload generators are each moving to distinct binary files.
Sound good?
Wednesday, April 8, 2009
Master of Orion 2 and Dosbox party
My friend Tristan and I have been fans of Master of Orion 2 for well over a decade at this point. Personally, the game is within my top three all time favorite games (also including Crusaders of the Dark Savant and Close Combat 2).
Anyways, a long time ago, we discovered that network multiplayer of MOO2 was deeply slow and sucky (like impossible to play for a protracted period of time). The games we have played against one another have either been hotseat or deeply time consuming and resulting in no real conclusion.
Well, no more. I finally got off my butt in regards to this issue this week and managed to get MOO2 running quite nicely in Dosbox. This resulted in us spending about 19 hours over the course of the last weekend playing the game the way it was meant to be played (to the bitter end of course, and several times over to boot)!
Anywho, this worked so well, that I am currently writing an NSIS installer which will pull all the necessary components off of the install CD, as well as properly configure DOSBOX such that nobody else needs to go through the decade long pain in the ass that we went through ever again.
Basically, what I have so far asks for the path to the install CD, copies the DOS only files to the HD, patches the game and sets up a local copy of dosbox to run it.
Later I will write a launcher which will get the dosbox environment running in some sort of sanitized location and execute various cli switches to configure the gameplay itself.
Weee!
-Ted
Anyways, a long time ago, we discovered that network multiplayer of MOO2 was deeply slow and sucky (like impossible to play for a protracted period of time). The games we have played against one another have either been hotseat or deeply time consuming and resulting in no real conclusion.
Well, no more. I finally got off my butt in regards to this issue this week and managed to get MOO2 running quite nicely in Dosbox. This resulted in us spending about 19 hours over the course of the last weekend playing the game the way it was meant to be played (to the bitter end of course, and several times over to boot)!
Anywho, this worked so well, that I am currently writing an NSIS installer which will pull all the necessary components off of the install CD, as well as properly configure DOSBOX such that nobody else needs to go through the decade long pain in the ass that we went through ever again.
Basically, what I have so far asks for the path to the install CD, copies the DOS only files to the HD, patches the game and sets up a local copy of dosbox to run it.
Later I will write a launcher which will get the dosbox environment running in some sort of sanitized location and execute various cli switches to configure the gameplay itself.
Weee!
-Ted
Subscribe to:
Posts (Atom)