On Wed, 17 Jan 2001, Sammy wrote:
>On Tue, 16 Jan 2001 16:38:46 -0800, you wrote:
>
>>load_char() is quite "blah". Hint: do_set() Also, the defaults should be
>>reflected in places like clear_char() instead of load_char().
>
>The reason I organized the parsing the way I did was for speed,
>basically compiling to a jump table that would only require a few
>string compares. I may try it the do_set way and see how it does
>under a load.
The idea behind the do_set way is that you can binary search (or fancier)
it later without changing the switch() all around.
>>The keywords need to be arbitrary length, not 4 characters. Otherwise you
>>end up with gems like "Hite" and "Wate" as keywords. Just split on the
>>first colon and use that for comparisons.
>
>My way is prettier and faster, but I can allow for both.
/* NOTE: destroys input */
void split_colon(char *input, char **postcolon)
{
char *pos = strchr(input, ':');
*pos++ = '\0';
*postcolon = pos;
}
char *foo = "Somekeyword: somevalue";
split_colon(foo, &post);
/* foo == "Somekeyword", post == " somevalue" */
Obviously you'll need error checking better than above. You'd also want to
call skip_spaces() on postcolon if you didn't want the space.
>>kill_ems == strip_cr
>>sprintbits == sprintascii
>
>Are those genolc functions?
Yes. sprintascii() is in genwld.c at the moment. strip_cr is in genolc.c
>Must be pretty old code. I've always hated setting up log() calls..
>Consider those gone.
Now I just wish I could do mudlog() without having to convert all the old
calls.
>>diskio.c: Actually, I'm fond of mmap(), but that doesn't mean I have a
>>problem with your code. I'd have to question "why?" though.
>
>Simple ignorance. I'd never heard of mmap() when I wrote it, and
>still don't know what it is, but I'll look into it.
http://www.circlemud.org/~greerga/mmaplib.c
Basically you make a file into a 'char *' to play with. Then you don't
have to worry about how much to read and the operating system pages in
whatever you need. The other advantage is that the operating system is
free to throw away the memory the file currently takes up because it knows
where to get it again. If you just read() into malloc() memory, it doesn't
know how to do that.
>I'm 100% self-taught, so I tend to reinvent the occaisional wheel when
>I don't realize the wheel exists (or sometimes just because the wheel
>seems like a cool thing to invent).
I generally try not to unless the previous wheel is square or its neat to
do.
>>>I think putting Oasis in stock 3.1 would be the way to go. Menu-driven
>>>ease of use is much closer to the spirit of the current circle community.
>>
>>It's a massive pain for bulk changes though.
>
>True, but there's no reason Oasis can't be made more powerful.
There exists a limit beyond a program should not go. I'm not sure where
that limit would be, but I do know OasisOLC won't read your e-mail.
>It's a big job and a lot of redundancy. My fantasy is a menu interface
>to command-line code where the menus can be defined in a simple table or
>text file, but that's a pretty complex project in itself.
I had the same sort of idea for defining the menus in OasisOLC.
--
George Greer | If it's about the CircleMUD mailing list,
greerga@circlemud.org | mail owner-circle@post.queensu.ca instead.
--
+---------------------------------------------------------------+
| FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
| Archives: http://post.queensu.ca/listserv/wwwarch/circle.html |
+---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/03/01 PST