27 Oct, 2008, Avaeryn wrote in the 1st comment:
Votes: 0
Thought I would just make a new thread for logs of the meetings. All logs will hopefully go here now.
27 Oct, 2008, Avaeryn wrote in the 2nd comment:
Votes: 0
*note: The you seen in this log is me. Just an FYI for those who need to know who is who.*

Unfortunately not many people came to the meeting this time. Here's the log.

RaM Roundtable 10.26.2008

You say 'Ok quix, log is on, so give the mud world the run-down on your adventures with the code.'
Quixadhal says 'Let's see. I've done a couple of global search and replace missions.'
Quixadhal says 'First to replace all the TRUE/FALSE instances with true/false. That might make performance slightly better when using C++ to compile (it won't have to typecast TRUE (1) from int to bool).'
You nod sagely.
Quixadhal says 'It makes vim happier, since true and false get syntax highlighted. :)'
Quixadhal says 'As suggested, music.c is toast.'
Quixadhal says 'Anyone who really liked it can always add it back as a snippet. :)'
Quixadhal says 'I also search/replaced all the line endings from \n\r to \r\n.'
You nod.
Quixadhal says 'That's the way TELNET wants them, and even though many people learned it the wrong way (myself included), it doesn't hurt.'
Quixadhal says 'It will actually fix regex matching in a few clients for patterns anchroed to the start of the line.'
Quixadhal says 'That always bugged me when I was playing MUD's more regularly. :)'
You snicker with him about your shared secret.
Quixadhal says 'Probably of more importance to most people… the code has been run through indent!'
You nod.
Quixadhal says 'For the gory details, you can now look at the .indent.pro file that's part of svn'
Quixadhal says 'I try to make sure everything that's checked in has been double-indented now, so you run indent once, then run it again and if the 2nd output differs from the 1st, something isn't right.'
Quixadhal says 'I don't expect anyone else to do that… but it looks good on the resume. *grin*'
Quixadhal says 'Let's see…. oh, I added signal handling to trap CTRL-C and SIGTERM.'
Quixadhal says 'So, if you run the mud in the foreground for debugging and hit ctrl-C, it saves all the players, kicks them, and shuts down.'
Quixadhal says 'Likewise, for doing a "kill PID"'
Retnur has entered the game.
Retnur says 'Roar'
Quixadhal tickles Retnur.
Quixadhal says 'and now that Retnur's here, I'll have to stop eating his pizza'
Quixadhal burps loudly.
Retnur says 'I just finished my meat lovers.'
Retnur says 'It was nice.'
You say 'hi retnur'
Retnur says 'Hello.'
You say 'pizza, mountain dew, cookies. help yourself'
You say 'and beer also'
Quixadhal says 'AND… new logging routines for all the kids.'
You nod.
You get a big pizza.
You eat a big pizza.
Retnur yawns.
Quixadhal says 'They still need a little tweaking, but they work'
Quixadhal says 'I think… I don't know that I've tried logging immortals in to see how annoying it is for them yet.'
Retnur says 'Have we decided to use C++ for the project yet?'
Retnur says 'Or is that still a few weeks away?'
You say 'something i wondered about here, if you guys don't mind me interjecting'
Quixadhal says 'be my guest. :)'
You say 'would it be possible to create the first version in C, to satisfy the C addicts. then later on, or whenever you want, make a C++ version.'
You say 'might be a lot of work, but that's one thing i've kind of noticed when any discussion regarding C++ enters these meetings. '
Quixadhal says 'Probably. It mostly depends on where we want to stamp version 1.0'
You say 'some people are really anti C++'
You nod.
Retnur says 'My whole problem with C zealots is the idea that C (or C++) is going to be relevant forever.'
Retnur says 'The only reason not to use C++ is not knowing it.'
Quixadhal says 'If it's just adding OLC, bits, and a few other things.. yeah.. .no big deal.'
You say 'what are your thoughts on the first version? after debugging and before features are added/modified?'
Quixadhal says 'If it's tracking down and fixing some of the more obscure bugs…. some of those WOULD be fixed by moving to C++'
Retnur says 'I think most people have a problem with object oriented design than C++ in general. I think they just don't realize you can utilize C++ without object oriented design.'
You say 'that was the only way i knew to address the split on C and C++'
Quixadhal says 'Probably so… I mean, I LOATHE streams, but nothing in C++ requires you to use them.'
Retnur says 'Well, regardless of what we end up doing I plan on working on a C++ revision of RaM.'
You say 'or would it even be possible to have one (or two) people volunteer to implement a c++ version while a c version is in the works as well'
Retnur says 'I never use streams'
You nod at Retnur.
You say 'that might be something you could do now then :)'
You chuckle politely.
Quixadhal says 'please take notes though… I'd like to move away from many of the more annoying C-isms myself. :)'
Retnur says 'I like the idea of throwing all of the prototypes for rooms, objects, mobs, etc, into std::map'
Retnur says 'I tested it on a stock rom and it ran very well.'
Retnur says 'Also bitset in C++ is more compelling to use than my bitmask code.'
Retnur says 'I've been mostly waiting for the project to really get underway before I do any coding on it. I don't want to do something that is counterproductive'
Quixadhal says 'Yes, that's why I've been trying to get most of this low level junk done… it's not the kind of stuff that splits very easily.'
You say 'quix do you have a timeframe for when features will be added or modified?'
Quixadhal says 'I'm still gunning for Halloween as being the end of this cleanup. :)'
Retnur says 'I was toying around with the boost library in C++ for pool memory management.'
Quixadhal says 'Anything that can't get done in another week, probably doesn't NEED to be done.'
Quixadhal says 'Retnur, how big of a task do you think it would be to convert to using std::string?'
Retnur says 'It's not that big of a task of you just do conversions at certain bottlenecks.'
Quixadhal says 'Really, if we didn't need to use char *'s other than doing OS calls, most of the memory management issues would go away.'
Retnur says 'Yeah.'
Retnur says 'It's trivial to change from char * to std::string throughout the code.'
Grumny has entered the game.
Grumny bows deeply.
Grumny says 'I guess I'm late'
Grumny smirks.
Quixadhal tries to pounce on Grumny, but there is no pounce. Sad kitty.
You say 'hi grumny'
Grumny says 'howdy'
Retnur says 'I kinda want us to have the mud MXP enabled.'
Retnur says 'There's a lot of codebases that are shipping standard with it now.'
Retnur says 'Even if it isn't used, it's a nice option.'
You nod.
You say 'so you think within a week debugging will be completed, quix?'
Quixadhal says 'I haven't ever really looked at MXP, but I see nothing wrong with supporting it.'
Retnur says 'Well…not much code different really.'
Retnur says 'The main thing on the server side would just be checking when they connect to see if htey have it enabled'
Quixadhal says 'I figured tonight I'd replace all the act() send_to_char() etc.. .with printf-enabled versions.'
Quixadhal says 'and thus removing lots of tmp, buf, tmp2, buf2, etc arrays.'
Retnur says 'Yes…that's something else std::string removes.'
Retnur says 'All of the bloated stack buffers.'
Quixadhal says 'Then it's attacking the bug list we've posted and seeing how many of those things still lurk around.'
Retnur says 'Doesn't rom come with a BUFFER structure?'
Quixadhal says 'Yep, it does.'
Retnur says 'That's kinda their solution to string buffers being dynamic.'
Quixadhal says 'I really want to try and clarify the way that whole memory mess works… finding out that objects aren't always copies of prototypes was a nasty surprise to me.'
Retnur says 'Yeah, I've long knew about that.'
Quixadhal says 'I guess when you try to modify a local object, it THEN does str_dup() to give you a copy… but that just smells like an explosion waiting to happen.'
Retnur says 'I think the entire idea that stuff should be done a certain way so it can be flexable with restring type commands and stuff like that should come second to having it work right. Then those systems can be worked into it.'
Retnur says 'I don't think objects should even have those fields'
Quixadhal says 'Agreed. I just want to understand how it actually works now, so I know if it IS working right. :)'
Retnur says 'There's no reason to give it to them.'
Retnur says 'Just make it refer to the index of the instance of hte object.'
Retnur says 'If we want to be able to restring object names away from the prototype then it needs to have an additional layer separate from that.'
Retnur says 'Not just a pointer that you never know if it's pointing to prototype or restring memory.'
Quixadhal says 'That might well be a C++ thing… I'm sure someone has a copy-on-write string class.'
Quixadhal says 'Anyways, with that in mind… what are the top 10 most annoying bugs we know about?'
Retnur says 'I don't know of any bugs per se that are annoying.'
Retnur says 'I think at the top of my list of things that need to be changed is the polling systems.'
Retnur says 'It's not too hard to fix and it has the most impact on preformance.'
Quixadhal nods.
Retnur says 'And aggressive_update is the worst offender.'
Retnur says 'Taking up to 50% or more on a mud with players just to check the few aggressive mobs that are in the game.'
Quixadhal says 'Oh, that reminds me.'
Quixadhal says 'The makefile now has an option to enable profiling.'
Quixadhal says 'If someone wants to run a game with profiling enabled and see how it works over a few days… that might be useful.'
Quixadhal says 'especially if you have a perl-bot that can "play" a few characters… keep meaning to write one.'
Retnur says 'In rom muds that are more developed than stock'
Retnur says 'A lot of issues start showing up'
Retnur says 'With the number of objects that are in the game'
Retnur says 'It's popular to remove inventory restrictions in rom and let players horde "collections" of items'
Quixadhal smiles happily.
Retnur says 'Then a lot of times when pfiles are loaded they are loading 15,000 objects'
Retnur says 'Or have a total of 100,000 object instances in memory'
Retnur says 'Often in a singularly linked list.'
Quixadhal says 'We always handled that with rent cost + weight.'
Retnur says 'I happen to know quite a few muds that didn't handle it at all.'
Retnur says 'And I don't think they should have to'
Retnur says 'It shoudl just be coded in a way it isn't going to break things.'
Quixadhal says 'You can have as many items as you want… but you have to pay to keep them, and you can't carry 1000000lbs on your back all the time. :)'
Retnur says 'Some games implement locker systems. But regardless'
Grumny says 'I remember the good old days of rent'
Retnur says 'If they design the game and want someone to have 15,000 objects'
Quixadhal says 'but yeah, if load times become relevant, that might need looking.'
Retnur says 'Then teh codebase shouldn't break'
Grumny says 'even with lockers it still ends up in the pfile doesn't it?'
Retnur says 'If they implement it that way'
Quixadhal says 'yeah, or at least in some file somewhere.'
Retnur says 'I kept my lockers separate from pfiles.'
Grumny nods.
Retnur says 'And it didn't load with pfiles…loaded witht he mud'
Quixadhal says 'You still have to store full object profiles, unless you dont' allow for things like equipment damage'
Retnur says 'That's true but if they're not associated with pfiles'
Retnur says 'Then you aren't having to deal with people logging in and out'
Retnur says 'And the load/save time becomes irrelevant.'
Quixadhal says 'yes, then the load doesn't stick with individual people, which is good.'
Retnur says 'My only suggestions would be designing it so that if you have multiple objects it saves in a better format in pfiles.'
Retnur says 'Especially if you have manyof hte same object.'
Retnur says 'LIke 100 flasks of healing'
Quixadhal says 'right… if objects don't have stats that can degrade, it should just be the vnum.'
Quixadhal says 'I mean, a sword can be damaged, but if you can't drink half a flask of healing.. .just knowing you have 20 vnum 3888 should be enough.'
Retnur says 'Well, rom doesn't have a degrading stat system.'
Retnur says 'In fact, everything is the same stats as the prototype.'
Grumny nods.
Retnur says 'Which makes it silly to even parse it by vnum in the pfile'
Quixadhal says 'I'd expect that to change with OLC and strings support… but if that's the case, yeah… vnum should be enough.'
Retnur says 'Just save it like "100 vnum 800" to load 100 of vnum 800'
Retnur says 'That's a gameplay issue.'
Retnur says 'And there's tons of rom muds that do not have variable stat objects.'
Quixadhal nods.
Retnur says 'If we're actually going to redesign how rom balances gameplay I have quite a few suggestions. :P'
Quixadhal says 'Oh, it just surprises me that a newer driver doesn't have all these things my old clunker has. :)'
Retnur says 'Rom isn't very advanced.'
Retnur says 'I'm not really a fan of the ascii text files for pfiles.'
Retnur says 'Fixed length binary mode files let you do some amazing things.'
Quixadhal says 'I prefer ascii as long as we're using files. I'd really prefer SQL, but that's another story.'
Retnur says 'It just doesn't make sense to save a file wher emost of the fields are not strings'
Retnur says 'All as a string'
Quixadhal says 'Then again, in my day we didn't use OLC… so being able to edit everything on disk was critical.'
Retnur says 'In a fixed length binary file you know exactly where sections begin and end'
Retnur says 'So if you decide you want to read a single field from a pfile. You can do that. efficiently'
Retnur says 'No need to read through the entire thing'
Retnur says 'Or if you want a single section loaded, you can do that'
Quixadhal says 'quick example…. if ROM used binary pfiles, and doesnt' ship with an immortal… how do you make an immortal? :)'
Retnur says 'RoM already has some code that when it is first turned on the first person to log in is instantly an immortal'
Quixadhal says 'it's broken then… didn't work for me. '
Retnur says 'Or what it is based on used to. Merc'
Quixadhal chuckles politely.
Grumny says 'I think it may be broken..'
Retnur says 'I like binary mode pfiles because the saving is so fast you can do it instantly when you change fields.'
Grumny says 'I had to edit a pfile when played with one'
Quixadhal says 'Also, if you use binary files and have to add fields, yo u then have to maintain a whole chain of upgrade_file routines.'
Retnur says 'manual saving is the whole reason item dups happen'
Retnur says 'No you don't.'
Retnur says 'There's plenty of well written muds that use binary pfiles.'
Retnur says 'Circle being one of them.'
Quixadhal says 'Yep, I've used Circle… adding or removing a field from the player object was a pain, because all the offsets changed.'
Quixadhal says 'unless you hand-updated the old files to the new version of the structure.'
Retnur says 'Okay. Well, what you're saying is ridiculous'
Retnur says 'That might be how it has been implemented'
Retnur says 'But you can do exactly what you can do in ascii mode'
Retnur says 'Read line by line'
Retnur says 'Examinign what the tag is'
Retnur says 'And it's still more efficient'
Retnur says 'Also you can create a header that tells you exactly where sections are automatically just from reading a header.'
Quixadhal says 'If I dump a data structure as binary, there aren't any tags to examine… you're talking about serializing?'
Retnur says 'I've never dumped entire data structures as binary.'
Retnur says 'You can save stuff using a tagging format. X bytes for the tag'
Retnur says 'The tag tells you how much data to read for the element'
Quixadhal says 'That's what I think of with binary files, as that's what Diku did, and I think what Circle does too.'
Retnur says 'header can tell you where sections for different types of tags begins and ends'
Retnur leaves south.
Grumny says 'I need to think about buying some dollars, the dollar hasn't been this weak in 10 years'
Quixadhal throws back his head and cackles with insane glee!
Quixadhal says 'Good luck… most of them are being spent on food and rent.'
Grumny nods.
Grumny says 'unfortunate but true'
27 Oct, 2008, David Haley wrote in the 3rd comment:
Votes: 0
If you're going to go with std::string, you might as well use a shared string library where appropriate. It's just as easy to deal with as std::strings, and it'll save considerably on memory. I have one lying around, as do several other people. And a word of caution: it's not totally trivial to replace char* with std::string. There are a few surprises lying around that you need to deal with. It's not intellectually hard, it's just somewhat tedious.
27 Oct, 2008, quixadhal wrote in the 4th comment:
Votes: 0
I figured someone must have a copy-on-write string library, as that just seems like a proper C++ thing to have (assuming you aren't mucking about twiddling individual characters as if it were C).

I expect to have to use a few char *'s and the .cstr() function for at least a handful of OS calls, but I'm hoping to get away without too much pain. If it's on the order of the const char * fix or less, I'll be happy. :)

Of course, there are a great many instances of strcat, strcpy, strdup, and all those happy tree friends that undoubtedly need poking. But hey, it makes my productive line count go up right? What, they don't pay by line anymore? Curses!!! :wink:
27 Oct, 2008, David Haley wrote in the 5th comment:
Votes: 0
What I've got is available here. It gets the job done for me, although it definitely has room for improvement (I need a better hash function, most notably).
27 Oct, 2008, Vassi wrote in the 6th comment:
Votes: 0
Quote
Retnur says 'I think most people have a problem with object oriented design than C++ in general. I think they just don't realize you can utilize C++ without object oriented design.'


It's true that you don't need OO design to use C++, by why wouldn't you leverage that? a MUD is a particularly strong candidate for OO design.
27 Oct, 2008, David Haley wrote in the 7th comment:
Votes: 0
Besides, a lot of people are already using object oriented design, just without realizing it. :wink: The nice thing about C++ is that you can actually enforce data visibility, as opposed to just trusting people to do the right thing. A lot of bugs would have been avoided in MUD code had people not been able to bypass the interface functions.
27 Oct, 2008, Runter wrote in the 8th comment:
Votes: 0
Vassi said:
It's true that you don't need OO design to use C++, by why wouldn't you leverage that? a MUD is a particularly strong candidate for OO design.


Because a lot of people want something very familiar to rom in this codebase. So the point is you don't have to redesign the entire codebase to utilize some C++ features.
28 Oct, 2008, quixadhal wrote in the 9th comment:
Votes: 0
Interestingly, I was doing a little reading about std::string, and it seems that some implementations (include the GNU version) build copy-on-write into std::string already!

I'm going to have to whip up some little test program to try and verify that, but it would be awfully nice if true.
28 Oct, 2008, quixadhal wrote in the 10th comment:
Votes: 0
Well, it does look like it's copy-on-write, but not fully shared. Not unexpected, but a shared version would indeed be nicer.

Quote
quixadhal@virt2:~$ ./testme
Array declared, empty
VmSize: 3228 kB

One element filled
VmSize: 3228 kB

ALL element filled by copy
VmSize: 3228 kB

ALL element replaced by direct assign
VmSize: 13260 kB

ALL element replaced by stream assign with different numbers
VmSize: 14052 kB
28 Oct, 2008, David Haley wrote in the 11th comment:
Votes: 0
It wouldn't surprise me if it's doing something relatively simple, where assigning one string into another shares memory, but if you independently assign "a" into two separate strings, it doesn't do any sharing. Still, that's a pretty good start, since most string sharing in MUDs involves just sticking one string into another. It is relatively rare that you assign one string, and then assign another that should be shared. That "waste" could be tolerated until the next reboot, at which point the sharing will happen normally again.

I'm quite pleased that you reported that Quix :smile: It makes me feel a lot better about std::strings…
28 Oct, 2008, Runter wrote in the 12th comment:
Votes: 0
I can't imagine std::string not meeting the needs of a mud for a string library.
28 Oct, 2008, David Haley wrote in the 13th comment:
Votes: 0
It meets the basic needs, sure, and is a great improvement over not doing anything, but there is still a case to be made for properly shared strings.

For example, std::string sharing will work for prototype-to-instance, but not if strings are shared across prototypes.
28 Oct, 2008, quixadhal wrote in the 14th comment:
Votes: 0
Yes, a full shared string system is what the ROM designers wanted to do, but there isn't any way to accomplish it in C, because there's no way to trap every way you can write to a char *.

Ideally, in C++, you'd have multiple spots that assign the same strings (constant or not), such as "To the north, lies even MORE grassland.". As long as they don't change, there's no harm having them all point to the same bit of string data. Since C++ allows
overloading of operators (including the array brackets), you can catch attempts to change any string and quickly make a copy before
letting the change occur.

Of course, you CAN try to go around behind the scenes and screw things up using pointers and naughty C routines, but if you've switched to using a string class, you really shouldn't shoot yourself in the foot by mixing it with that nonsense. If you find the need to muck with pointers, your string class is deficient. :)

It looks like the linux implementation of std::string does copy-on-write, but makes no attempt to examine the contents of the strings. That's probably a speed issue, since more people would complain about string operations being slower, than about them not saving as much memory as they could. My test program made an array of 100000 strings, and initialized them all to point at s[0], and that too no extra memory (no surprise). When I then looped through and started setting them all to the same constant string, the memory rose as each string was pointed to a new instance of the same constant (disappointing, but again, no surprise).
28 Oct, 2008, Runter wrote in the 15th comment:
Votes: 0
DavidHaley said:
It meets the basic needs, sure, and is a great improvement over not doing anything, but there is still a case to be made for properly shared strings.

For example, std::string sharing will work for prototype-to-instance, but not if strings are shared across prototypes.



I don't really think that it becomes too big of an issue to not share prototype string memory. I think that's what I was trying to imply.

std::string accomplishes the bulk of the work. Anything else is nice, but hardly clutch.
28 Oct, 2008, David Haley wrote in the 16th comment:
Votes: 0
quixadhal said:
Yes, a full shared string system is what the ROM designers wanted to do, but there isn't any way to accomplish it in C, because there's no way to trap every way you can write to a char *.

Well… you could, you'd just have to trust that people respect the interface functions. (Good luck with that…)

quixadhal said:
That's probably a speed issue, since more people would complain about string operations being slower, than about them not saving as much memory as they could.

And that was a wise decision. I don't really want the library trying to outsmart me (or itself, as it were). Copy-on-write sharing is basically free, so it makes lots of sense to do that.

The link I gave provides a full C++ class system that takes care of all this. Not necessarily perfect (although I don't know of any issues), but it's worked for me so far. It could maybe use more interface functions; I add those as I need them.


EDIT: replying to Runter…
I don't have the numbers around anymore but a fair bit is saved by fully sharing strings, especially as the world grows. There are lots of exit keywords that repeat, shared prompts, shared room names, and so forth. Sharing with the prototype is probably the biggest saving, but the other savings aren't negligible. And using a self-managed string class is extremely easy.
Second edit: I think we are in full agreement here……
28 Oct, 2008, quixadhal wrote in the 17th comment:
Votes: 0
Yep, it sounds to me like (when we finally do make the C++ switch… probably after we have SNV arranged to keep the Caveman branch (CRaM!) for C-only folk), we all feel std::string is a good easy-to-use replacement for ROM's shared string system. Finding or writing a fully shared system can be a side-project for someone who thinks the savings will be worth the time. :)
28 Oct, 2008, Runter wrote in the 18th comment:
Votes: 0
Quote
(when we finally do make the C++ switch… probably after we have SNV arranged to keep the Caveman branch (CRaM!) for C-only folk)


I'm eager to start getting to work on the C++ branch once we get going.
29 Oct, 2008, David Haley wrote in the 19th comment:
Votes: 0
quixadhal said:
Finding or writing a fully shared system can be a side-project for someone who thinks the savings will be worth the time. :)

Uhh… :rolleyes:
0.0/19