Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - wodan

Pages: [1] 2 3 ... 29
Discworld Discussion / Re: Distlib, distlib, wherefore art thou distlib?
« on: February 01, 2015, 11:33:33 am »
shame the betting companies haven't picked this up yet, I'd love to know the odds for 2015, before 2020, before 2100 ;)

Drivers / Re: FluffOS 3.0-alpha7.4
« on: November 07, 2013, 03:54:43 pm »
call_out() isn't really designed to operate in real-time.  MudOS/FluffOS has a virtual time system that tries to adapt for situations where resources are limited, by ensuring that if you do a call_out() in 5 seconds, it happens at least 5 seconds later.

If the call_out() is happening early, that is indeed a bug.

only true in the driver's virtual time, if that happens to be 5 seconds behind the real time, it'll happily do your call_out in the same real time second, which is why on any properly running mud with little lag you can actually use time() calculate when the next whole hour is and set a call_out to trigger at that time, and it'll run when the virtual time reaches that time, if there's no lag at that moment it'll be the time you wanted, and if there is lag, there's nothing that could make it run on time anyway, or at least not until we get multithreading, that's why time() returns virtual time so log files will look nice and acurate, and there is real_time() for when the actual time matters, they should be the same most of the time.

Drivers / Re: Gather output of mud_status(1)
« on: September 06, 2013, 04:23:52 pm »
well, it could be result of any memory corruption actually.   all my current muds uses very little shadowing, it would be nice to test more on that area.  (have you tried following Valgrind section?)

I do try to run with valgrind sometimes, but within 10 minutes everything slows to a crawl and nothing useful comes out anymore, while those crashes would typically happen after about 1 or 2 hours. I have fixed things that showed up, but it never seemed related to those particular crashes (it did find some other ones which were already fixed).

Drivers / Re: Gather output of mud_status(1)
« on: September 06, 2013, 04:19:48 pm »
on a slightly related note

we noticed the other day that
int i = memory_info();
return  memory_info()-i

actually returns negative numbers so memory_info() will be systematically too low (also because it doesn't track all allocations)

despite that it's just gone negative (32 bit wrap) on discworld, should make it a 64 bit counter, perhaps it already is in 3.0

Drivers / Re: Gather output of mud_status(1)
« on: September 06, 2013, 04:13:48 pm »
it's small because when it was big some interaction between shadows and the apply cache would crash us, I could never find the cause for those, however the apply cache code has changed in 3.0 and it may have been related to the set_jump problems, so we could try a bigger cache again when 3.0 is out

Drivers / Re: Virtual time in fluffos
« on: September 06, 2013, 04:11:09 pm »
if they stay in line with heart_beat that would certainly help, but it wouldn't be much good for things like our cron handler, things that need to happen at specific times are rather special though, so it wouldn't be too much effort to change the code for those, perhaps we can add a call_out_at() call or something to run at a specific time, that would be easier for the code as well (compared to having to calculate how many seconds away something is). If that would be available it may well be an improvement over the current way.

Drivers / Re: Gather output of mud_status(1)
« on: September 06, 2013, 02:59:48 pm »
that wasn't quite the busiest moment, but I don't think it changes all that much

Drivers / Re: Gather output of mud_status(1)
« on: September 06, 2013, 02:57:56 pm »
enjoy, some numbers will have wrapped

"Open-file-test succeeded.
current working directory: /home/atuin/lib

add_message statistics
Calls to add_message: 25822882   Packets: 17220288   Average packet size: -123.344498

Function cache information
% cache hits:         74.32
call_others:     4233179030
cache hits:      3146018061
cache size:           65536
slots used:       311258561
% slots used:     474942.87
collisions:       775902408
% collisions:         18.33

Object name hash table status:
Average hash chain length:             3.31
Average search length:                 1.06
Internal lookups (succeeded):    5927713 (5927713)
External lookups (succeeded):    1430449947 (1367299778)

Heart beat information:
Number of objects with heart beat: 919, starts: 107609
Percentage of HB calls completed last time: 100.00

All strings:
-------------------------    Strings    Bytes
All strings:          8541417 196199272 + 213382616 overhead
Total asked for         231000118 -659910111
Space actually required/total string bytes 3%
Searches: 581126119    Average search length:  0.778

Call out information:
Number of allocated call outs:     5800,   324800 bytes
Current length: 2630

Drivers / Re: Virtual time in fluffos
« on: September 06, 2013, 02:53:26 pm »
MudOS did have call_out based on the heart_beat interval, which was really annoying (as dw has a 2 second heart_beat).
Virtual time makes sense when you do get lag as you can still do everything as you catch up with real time, but it's also a big gain when you're not lagged as getting time() just gets a global variable instead of having to do a system call. It also makes it easier to do a nice constant rate call_out loop, if you're late once, you'll be back in the correct time next time round, where if it was based on real time it would just get delayed further all the time, and you'd actually have extra lag from all the calls to get the current time.
And unless your mud is really laggy (and then you have bigger problems to look at) players won't be able to tell if the slightly shorter time between calls was catching up with netlag or actually a problem on the mud

and yes, discworl relies on everything actually happening, even if it's late, it's done miracles in cutting down player complaints about death through lag. (of course these days lag is rare anyway, but when it happens it's good to know that all code assumptions will still hold!).

Drivers / Re: Virtual time in fluffos
« on: September 05, 2013, 01:52:28 pm »
also wouldn't like delaying call_out from the current time, as that would upset the call_out loops that keep things going nice and regular, lag effects would just keep building up (also, unlike the heart_beat thing, call_out has always been on virtual time on mudOS as well)

Drivers / Re: Virtual time in fluffos
« on: September 05, 2013, 01:48:25 pm »
wouldn't be player friendly at all on dw (which is why I changed it to never miss anything)
hitpoints are added in hear_beat, but more interesting actions that hurt you are from call_out, so missing heart beats can be deadly

Drivers / Re: Long standing bug in FluffOS
« on: September 02, 2013, 02:40:55 pm »
it's actually quite useful to have the 0, for instance after restoring an object from disk, you can test if a value is 0 (didn't exist in save file, so you may need to set a few things) or just empty, just because you couldn't think of any use doesn't mean there are none, and there are actually many, even undefined (which most of those 0s in the wrong type are) is useful as you can detect if an integer was never set instead of just the value 0.
You could make a case for setting non-integer variables to undefined instead of 0 when you assign a 0 to them.

Drivers / Re: Long standing bug in FluffOS
« on: August 31, 2013, 07:13:10 am »
My reply would be that it's a shame that (probably) none of the mudlibs would run on your shiny new driver, so have fun writing everything from scratch on your own.

don't just go and add object arguments, adding one to command() would be a bit of a security problem! (on muds with add_action anyway), solvable but might get some people by surprise when it's already too late.

Drivers / Re: fluffos 3.0-alph6
« on: July 16, 2013, 02:12:54 pm »
the stack would have whatever caused the destruct to be called in it, the driver doesn't tend to call it at all, that's what clean_up is for, so it would probably be fine, security wise. Not sure what to do when you get an error in the destructor though.

Pages: [1] 2 3 ... 29