Navigation
User login
Upcoming events
Recent Events
- 43 weeks 3 days ago
- 46 weeks 1 day ago
- 1 year 3 weeks ago
- 1 year 5 weeks ago
- 1 year 5 weeks ago
Newest Games
Search
Who's online
MarMOTS update #4
So, I just wanted to talk about MarMOTS a little bit. I'm still working on MarMOTS every so often in my spare time. I had two goals that I wanted to achieve before I put it back online.
Goal #1: User authentication.
This works; you can now login to MarMOTS using your Glorious Trainwrecks username and password.
Goal #2: Saving.
Not explicitly stated, but required for Vision #2 of my 8-step vision, I want to make sure that if I bring the server down, I can bring it back up without everything being lost forever.
This has been trickier than I'd anticipated. I thought I would just chuck everything into an object database, and the de-facto object database for Python would appear to be ZODB. What I didn't count on was that ZODB was not even remotely designed to process the huge volume of changes I would be throwing at i; the way that it saves is to append the new data to the end of a file. In my original plan, this file would quickly be filled up with changes in the cursor blinking status if I saved it all the time.
Of course, then I realized that saving it all the time is infeasable anyway, because that would mean WRITING THE SCREEN TO DISK in addition to sending it over the network. No good.
So I guess I'll implement regular checkpointing, which may mean brief pauses every half hour or something. I'm keeping my eye on POD, but that project is young enough that it makes me nervous about depending on it. I think at this point the simplest thing is to just dump the whole thing to a pickle file and be done with it; I'm pretty sure I'll be able to migrate to a more complicated scheme later.
Maybe goal #3: Dedicated hosting.
MarMOTS has a deliberately inefficient design; I burn lots and lots of CPU so that I don't have to think about cache invalidation. I share the server that Glorious Trainwrecks runs on with lots of other people; the CPU time is not really mine to burn. So I'm thinking the only reasonable solution is to move to my own (virtual) server, where I don't have to care that people drawing ASCII dongs is slowing down other peoples' websites. Of course, I'd want to minimize the time I was spending $20/month solely to host MarMOTS by moving all my shit to the new server, but that's not a project I really want to undertake QUITE yet.
So, yeah, if you guys are excited to play with MarMOTS some more, make some noise in the comments!
Comments
i'm excited to play with
i'm excited to play with marmots some more!
we want MarMOTS yes we do we
we want MarMOTS
yes we do
we want MarMOTS
how about you!!!!!!!
Honestly $20/mo is a bit
Honestly $20/mo is a bit steep if MarMOTS is just a shared screen (and it seems surprising that it's so CPU hungry to do that... c'est la vie) -- but as a possible shared play space, THATS when the prospect starts to get cool again...
RAR RAR RAR RAR RAR
DONKA DONKA DONKA DONKA DONKA
Further update: Goal #3 has
Further update:
Goal #3 has been met; I ponied up the $20/month for a Linode and I'm about three quarters of the way through setting everything up. I'll be transitioning Glorious Trainwrecks to a new server sometime fairly soon, at which time all site outages and problems will suddenly become my fault.
Goal #2 continues to be slippery. I've realized that it would be irresponsible for me to just dump objects to disk without putting at least some thought into how I'll upgrade everything when the representation of the objects changes. This has led to a simple framework for versioned objects, and some small refactorings to certain generic objects to make them upgradable. It's also leading to some efficiency improvements, as there are actually quite a lot of objects that I simply don't need to save. (Putting the effort into not saving them now means I don't have to put the effort into upgrading them later.)
Unfortunately, doing all these refactorings takes time, so no new MarMOTS for you guys just yet. However, if you guys really want, I can throw up the old MarMOTS in which everyone is anonymous and everything is vapourized when I take the server down.
Gaah why can't things ever work the way I need them to
So, one of the highly touted features about Stackless Python is its ability to suspend a microthread, save ("pickle") it to disk, then bring it back to life -- possibly even on another machine. I had been assuming that the way that this worked was that, for each stack frame, the pickler kept a list of the possible exit points, and the saved state of a given frame would be a reference to the function by name, an index into this list, plus any local variables. This would allow me to make small changes, like one-liner bug fixes, to running functions, and still have them pick up where they left off.
Nope! The way that it actually works is to save the full bytecode of the function, meaning any changes I might make to the code are completely ignored. Argh.
I'm not relying on my expected behaviour... YET. The scripting language will have to work in a more robust way. But I think I can make that work.
Anyway, other than that, the news is that persistence is finally working, so except for one final hitch, I can start building game again. That final hitch is that I can't seem to find a way to draw something the bottom-right corner without causing the entire display to scroll down a line. This used to work because I cut off the rightmost column, but I _really_ want to be running in 80x25. So I'll have to find some workaround. Any ANSI art aficionados that can find examples of 80x25 pictures that don't scroll off the screen on a BBS, please post links.