Fri May 29 23:54:38 2009
[dgd]
Kalinash@Fire and Ice: ok, i'm finally getting to the liqour store... what was that stuff i was supposed to try?
Sat May 30 01:14:37 2009
[dgd]
Subversion@Way of the Force: Nullinfinite committed Gurbalib revision 259 to svn://wotf.org/gurbalib :
Sat May 30 04:18:51 2009
[dgd]
Subversion@Way of the Force: Nullinfinite committed Gurbalib revision 260 to svn://wotf.org/gurbalib : added a define: M_UNDROPPABLE
Sat May 30 04:40:33 2009
[dgd]
Subversion@Way of the Force: Nullinfinite committed Gurbalib revision 261 to svn://wotf.org/gurbalib : Simplified verb can/do functions. Can functions will always return a 1 if they are available, and a 0 when not. Returning strings for an error message from a can_x function has been removed as a feature.
Sat May 30 12:16:25 2009
[dgd]
Subversion@Way of the Force: Aidil committed Gurbalib revision 262 to svn://wotf.org/gurbalib : Redid r258 and disabled debug output in parse_d. If you really want the debug output, see the top of parse_d and add the proper define to /include/local_config.h
Sat May 30 18:21:03 2009
[dgd]
Subversion@Way of the Force: Aidil committed Gurbalib revision 263 to svn://wotf.org/gurbalib : Added documentation for the get/set_tlvar afuns and some general documentation on the use of tls variables
Sat May 30 19:52:43 2009
[dgd]
Aidil@GurbaDev2: committed to maintaining an extension to the dgd driver, and a mudlib for it :)
Sat May 30 21:11:50 2009
[dgd]
Aidil@Way of the Force: hmm. getting over 2 hours usage on my laptop from a 40% full battery.
Sat May 30 21:12:29 2009
[dgd]
Aidil@Way of the Force: and could increase that with another 30 mins if I would reduce brightness somewhat
Sat May 30 22:27:53 2009
[dgd]
Quixadhal@Bloodlines: Hrmmm, player commands have create() called when first accessed.... is there a function that would be called if they were updated? Or do they get destroyed and totally re-created?
Sat May 30 22:29:26 2009
[dgd]
Aidil@Way of the Force: the part about 'dealing with changes' is what you want.
Sat May 30 22:29:59 2009
[dgd]
Aidil@Way of the Force: it should also work when using update on an object directly, if not then you have found a bug :)
Sat May 30 22:33:13 2009
[dgd]
Quixadhal@Bloodlines: Ok, so for commands, setup works for both the first call and any subsequent updates.
Sat May 30 22:42:27 2009
[dgd]
Quixadhal@Bloodlines: There, a perl script and a tiny new command, and now I can see my svn revision. :)
Sat May 30 22:43:23 2009
[dgd]
Quixadhal@Bloodlines: It may not work on windoze, or other weird platforms... it relies on the top level directory appearing to always get updated whenever anything is commited.
Sat May 30 22:43:30 2009
[dgd]
Aidil@Way of the Force: sounds like you did something similar to how this mud knows about firewall rules on its host that are related to the mud.
Sat May 30 22:44:03 2009
[dgd]
Aidil@Way of the Force: that also depends on you doing svn update in the top level directory.
Sat May 30 22:44:44 2009
[dgd]
Quixadhal@Bloodlines: I was tempted to try and shell out, but for security reasons, I figured making the admin type "generate_svninfo.pl" after they do an update is easier.
Sat May 30 22:45:56 2009
[dgd]
Aidil@Way of the Force: heh. I actually use a small monitoring daemon that watches a specific dir and writes answers in response to requests found there.
Sat May 30 22:46:31 2009
[dgd]
Aidil@Way of the Force: works both ways, mud has a similar monitoring service watching for updates from svn.
Sat May 30 22:47:11 2009
[dgd]
Quixadhal@Bloodlines: The last time our admin bothered to run generate_svninfo, Bloodlines was at Revision 263. Supposedly, aidil updated things to Revision 263 on 2009-05-30 13:21:05 -0400 (Sat, 30 May 2009)
Sat May 30 22:47:27 2009
[dgd]
Aidil@Way of the Force: post commit script writes info to a file, mud picks up the change and handles things.
Sat May 30 22:47:37 2009
[dgd]
Quixadhal@Bloodlines: The first is "Revision", the second is "Last Changed Revision" :)
Sat May 30 22:48:51 2009
[dgd]
Quixadhal@Bloodlines: I recall the svn people grumbling about the lack of a way to get the globally highest revision number... maybe I can poke around for a script to do so.
Sat May 30 22:49:42 2009
[dgd]
Quixadhal@Bloodlines: In any case, I figured it'd be a good stub for the "svn" command, which someday will be able to do much more, and will come with cookies.
Sat May 30 22:51:23 2009
[dgd]
Aidil@Way of the Force: for that matter.. how do you think about hiding the .svn directories for lpc code?
Sat May 30 22:52:30 2009
[dgd]
Quixadhal@Bloodlines: I was thinking about that.... it's probably a good idea to hide .cvs, .svn, and maybe a few others as well.
Sat May 30 22:53:15 2009
[dgd]
Quixadhal@Bloodlines: Although there are some files that might not be worth trying to hide... for example, vim makes a .swp file if you have a session open
Sat May 30 22:53:58 2009
[dgd]
Aidil@Way of the Force: hiding stuff is relatively expensive, so should be limited to cases where it really makes sense.
Sat May 30 22:54:01 2009
[dgd]
Quixadhal@Bloodlines: I kindof hate restricting the namespace... but I also hate someone hurting themselves by mucking with the .svn directory's content in ed.
Sat May 30 22:55:26 2009
[dgd]
Quixadhal@Bloodlines mutters about dusting off the preg driver mod...
Sat May 30 22:56:33 2009
[dgd]
Aidil@Way of the Force: if preg would help, it could probably be done with parse_string as well.
Sat May 30 22:57:39 2009
[dgd]
Quixadhal@Bloodlines mutters about the programmer cost of having to define a grammar just to match a handful of string patterns.
Sat May 30 22:58:43 2009
[dgd]
Aidil@Way of the Force: the point being that a very small number of sscanfs are still much faster then either a regexp or parse_string match.
Sat May 30 22:58:56 2009
[dgd]
Aidil@Way of the Force: and this getting called a lot in certain cases.
Sat May 30 22:59:04 2009
[dgd]
Quixadhal@Bloodlines points at you and utters '/^([\w\s-]+):\s(.*)$/;', again!
Sat May 30 23:00:26 2009
[dgd]
Quixadhal@Bloodlines: I'm just used to being able to do things like ".(foo|bar|x) to match a bunch of suffixes.... you'd have to use a loop on all the choices for sscanf.
Sat May 30 23:01:33 2009
[dgd]
Quixadhal@Bloodlines: and a quick check like filenames isn't something I'd really want to define (and maintain) a whole parse_string setup to do. But, that's what I get for using perl... :)
Sat May 30 23:01:36 2009
[dgd]
Aidil@Way of the Force: yes, but for a very small number, that is still going to be a fair bit faster, and that is really relevant in this case.
Sat May 30 23:02:24 2009
[dgd]
Aidil@Way of the Force: the loop + sscanf, or even 2 or 3 hardcoded sscanfs.
Sat May 30 23:02:44 2009
[dgd]
Quixadhal@Bloodlines: Is it really that expensive? I mean, I would think the I/O from doing the directory read is an order of magnitude above any reasonable amount of string mangling.
Sat May 30 23:02:53 2009
[dgd]
Aidil@Way of the Force: I understand your point, pointing out that in this case, spending ticks is going to hurt A LOT.
Sat May 30 23:05:18 2009
[dgd]
Aidil@Way of the Force: when you have something that potentially gets called thousands of times during a single execution round, a few ticks simply matter.
Sat May 30 23:07:32 2009
[dgd]
Quixadhal@Bloodlines: Slightly off topic... how does the number of ticks available get determined? IE: how do you decide what a reasonable number is for a given set of hardware and a given number of lpc threads?
Sat May 30 23:08:23 2009
[dgd]
Quixadhal@Bloodlines: I know DGD doesn't automatically give you more, just because you run on a faster CPU... which implies you have to pick good defaults or your hardware sits idle.
Sat May 30 23:08:27 2009
[dgd]
Aidil@Way of the Force: it is defined in std.h, and based mostly on trial and error
Sat May 30 23:09:44 2009
[dgd]
Quixadhal@Bloodlines: Maybe hiding them at such a low level isn't necessary... How expensive would it be to make them unwriteable at the permissions layer?
Sat May 30 23:10:29 2009
[dgd]
Quixadhal@Bloodlines: I mean, the "ls" command can always filter them out of the display, which would stop 95% of people poking at them.
Sat May 30 23:10:44 2009
[dgd]
Aidil@Way of the Force: well, problem stays the same, but less likely to get called a gazillion times
Sat May 30 23:10:52 2009
[dgd]
Quixadhal@Bloodlines: Then you'd just want to NOT have code be able to write and muck with them.
Sat May 30 23:11:23 2009
[dgd]
Aidil@Way of the Force: oh, filtering them from ls isn't the problem, and actually not needed.
Sat May 30 23:12:51 2009
[dgd]
Aidil@Way of the Force: get_dir() can do that, problem is access. readability gets checked a lot more then writability however. Since most is world readable, that is no problem because world readable is extremely cheap.
Sat May 30 23:13:17 2009
[dgd]
Quixadhal@Bloodlines: I don't think read access matters much... there aren't any passwords or anything stored in there.
Sat May 30 23:14:44 2009
[dgd]
Quixadhal@Bloodlines: How many places can you write to files? save_object? Anything else?
Sat May 30 23:15:55 2009
[dgd]
Quixadhal@Bloodlines: Ok, save_object, write_file, log_file. So, three api points that would need to be protected.
Sat May 30 23:24:27 2009
[dgd]
Aidil@Way of the Force: you will be sure you aren't missing anything that way.
Sat May 30 23:26:17 2009
[dgd]
Quixadhal@Bloodlines: Either way, if(path[strlen(path)-4..] == ".svn") fail?
Sat May 30 23:28:19 2009
[dgd]
Aidil@Way of the Force: I'd rather go for a sscanf() so you also catch things like .svn/blah
Sat May 30 23:34:54 2009
[dgd]
Aidil@Way of the Force: btw, I will provide documentation on the security system once it has been finished a bit more, but till then you'll have to make do with reading the code, and keeping in mind I'll change some of the internals still (tho not the api if all goes well)
Sat May 30 23:35:37 2009
[dgd]
Quixadhal@Bloodlines: Sure.. just poking at sscanf vs. strstr. strstr seems more expensive than it should be.
Sat May 30 23:37:19 2009
[dgd]
Quixadhal@Bloodlines: eval a="hello"; return sscanf(a, "%*slo"); vs eval a="hello"; return strstr(a, "lo");
Sat May 30 23:37:54 2009
[dgd]
Kalinash@Fire and Ice: (if you want inneficient string manipulation routines)
Sat May 30 23:39:31 2009
[dgd]
Quixadhal@Bloodlines: Is strstr implemented in lpc, and thus just uses sscanf?
Sat May 30 23:40:14 2009
[dgd]
Kalinash@Fire and Ice: i bet that strstr() in lpc is faster than explode/implode in C :)
Sat May 30 23:44:00 2009
[dgd]
Quixadhal@Bloodlines: Sometimes, I think DGD suffers from the "When all you have is a hammer, everything looks like a nail" syndrome. Mind you, it's a very nice hammer!
Sat May 30 23:46:15 2009
[dgd]
Quixadhal@Bloodlines: Yep, it scales... sscanf takes 43 ticks to find things like that. strstr ramps up.
Sun May 31 00:24:42 2009
[dgd]
Aidil@Way of the Force: btw, after I've redone the login code and have domain and group permissions working I want to do a new release.
Sun May 31 00:31:27 2009
[dgd]
Aidil@Way of the Force: I'm going to take the login code out of the player object, it has no business there. When the player object is no longer involved in login, it becomes easy to have an account system with multiple characters for each login.
Sun May 31 00:33:12 2009
[dgd]
Quixadhal@Bloodlines: That sounds good. I always like the idea of a seperate connection/player/body object myself. That way you handle accounts at the connection/player level, and you can do things like polymorph/possession/etc at the player/body level.
Sun May 31 00:34:32 2009
[dgd]
Aidil@Way of the Force: small issue with that is that not all bodies contain enough functionality for that.
Sun May 31 00:35:25 2009
[dgd]
Aidil@Way of the Force: player object is somewhat special for a number of reasons, including providing its privileges for the stack based security.
Sun May 31 00:35:40 2009
[dgd]
Quixadhal@Bloodlines: Well.... if you're a lamppost, expect limited mobility. *grin*
Sun May 31 00:36:51 2009
[dgd]
Aidil@Way of the Force: that is not the problem tho. The player body object contains functionality required by the system for the concept of a player to work at all.
Sun May 31 00:37:12 2009
[dgd]
Aidil@Way of the Force: ie, it can not be taken out of the equation without a major rewrite.
Sun May 31 00:37:57 2009
[dgd]
Aidil@Way of the Force: it is however possible to seperate the login NAME from the in-game name, and allow a login to select one of a list of in-game names.
Sun May 31 00:38:40 2009
[dgd]
Aidil@Way of the Force: taking over other bodies without having a real player object involved however is not possible as it is now.
Sun May 31 00:39:10 2009
[dgd]
Aidil@Way of the Force: which is hardly a problem because redirecting commands to another body is simple and is implemented.
Sun May 31 00:41:23 2009
[dgd]
Aidil@Way of the Force: consider that about everything that defines a specific character to the game is contained in the player body object.
Sun May 31 00:41:44 2009
[dgd]
Quixadhal@Bloodlines: It's mainly just breaking the physical body apart from the command parser/privs system. If NPC's and PC's use the same underlying mechanics, except one has a command interpreter hooked to a connection, and the other has an AI routine, it becomes more flexible to do interesting things. But yeah, not in the near future, for sure.
Sun May 31 00:43:12 2009
[dgd]
Aidil@Way of the Force: it is also breaking anything that the game might want to remember about a player apart from the body.
Sun May 31 00:44:14 2009
[dgd]
Aidil@Way of the Force: not to mention, stack based security simply requires that there is an object representing the in-game character that it can trust, which means it can't be any random body object.
Sun May 31 00:44:39 2009
[dgd]
Aidil@Way of the Force: you can seperate that all from the body, but you end up requiring another object for it.
Sun May 31 00:46:18 2009
[dgd]
Aidil@Way of the Force: in case of gurbalib, command parsing and actions are quite seperated already, and the parsing is centralized for a large part.
Sun May 31 00:46:44 2009
[dgd]
Aidil@Way of the Force: which is why the current possess implementation is rather simplistic yet works very well.
Sun May 31 00:47:55 2009
[dgd]
Quixadhal@Bloodlines: Right... at the moment, you have a player object that is everything. If you split a connection object off and let it handle login authenticaion and possibly a subset of privs, you gain accounts and protection for wizard powers (you only get elevated privs if the player AND account allow it, for example).
Sun May 31 00:48:22 2009
[dgd]
Aidil@Way of the Force: please, go read the code because your assumptions are wrong.
Sun May 31 00:49:44 2009
[dgd]
Aidil@Way of the Force: as said, I will document the security stuff once it is settled a bit more, till then, the code is really the place to look. If I go explain the details here on why exactly it works as it does I could as well write the documentation now.
Sun May 31 00:50:26 2009
[dgd]
Aidil@Way of the Force: but the connection object has been split off, and always has been.
Sun May 31 00:51:07 2009
[dgd]
Aidil@Way of the Force: for an account system to work, there must be differnt and specific privileges for both the connection and the player object.
Sun May 31 00:52:15 2009
[dgd]
Aidil@Way of the Force: beyond that, what you'd achieve with splitting player and body up as well is a cleaner interface at the expense of more resource use.
Sun May 31 00:52:38 2009
[dgd]
Aidil@Way of the Force: and with absolutely zero gain in functionality.
Sun May 31 00:53:35 2009
[dgd]
Aidil@Way of the Force: the player object as it is can control another body object in exactly the way you want.
Sun May 31 00:55:00 2009
[dgd]
Aidil@Way of the Force: its 'native' body however is integrated into the player object.
Sun May 31 00:55:44 2009
[dgd]
Quixadhal@Bloodlines: Can it permenantly take over a new body (not just issue commands)? Can it exchange the connection object for an AI routine and become an NPC while offline? I want a lot. :)
Sun May 31 00:56:57 2009
[dgd]
Aidil@Way of the Force: because it uses exactly the same body code, it can be controlled by an AI yes. Permanent is a matter of you not removing the remote body link.
Sun May 31 00:59:43 2009
[dgd]
Quixadhal@Bloodlines: So, there's no real difference between a seperate body object and just always giving someone a "remote" body link at creation time and exchanging it when you want to switch?
Sun May 31 01:01:06 2009
[dgd]
Aidil@Way of the Force: not in terms of functionality, there is in terms of resource use becaue you are using an extra object for the default case.
Sun May 31 01:02:10 2009
[dgd]
Aidil@Way of the Force: enough to be a worry? not really, but not needed either imho since well, it purely serves to beautify an interface imho.
Sun May 31 01:02:36 2009
[dgd]
Quixadhal@Bloodlines: right, I see that. I'm going to want to try some benchmarking, as a lot of these tick limits seem very small considering the hardware I'm using.
Sun May 31 01:04:05 2009
[dgd]
Quixadhal@Bloodlines: Not that I have a "god" machine, but it's still an order of magnitidue faster than the machines we used to run lp muds on, so I'm really curious just how much room those numbers have to move.
Sun May 31 01:05:16 2009
[dgd]
Aidil@Way of the Force: it depends a bit on use.. and will be quite different on dgdmp
Sun May 31 01:06:38 2009
[dgd]
Aidil@Way of the Force: ie, on my router, I allow about 10000 times the amount of ticks compared to what I allow on way of the force, which runs on the same machine.
Sun May 31 01:07:09 2009
[dgd]
Aidil@Way of the Force: reason is that efficiency is more important then latency for the router, but responsiveness is everything for the mud.
Sun May 31 01:08:44 2009
[dgd]
Quixadhal@Bloodlines: Good old P3-933 on the server... 24 times faster than the 40MHz 486 we ran on 15 years ago, so it seems like I shouldn't be worrying MORE now than I did back then.
Sun May 31 01:09:15 2009
[dgd]
Aidil@Way of the Force: back then we also had max ticks set a fair bit lower tho.
Sun May 31 01:09:57 2009
[dgd]
Aidil@Way of the Force: but also many more things implemented in the driver :P
Sun May 31 01:11:28 2009
[dgd]
Quixadhal@Bloodlines: It would just be nice to know, given a default tick setting, how many players/npcs can I have at 50% CPU use? And how much can I bump the tick settings before responsiveness becomes noticeably slower? We need a spreadsheet. *grin*
Sun May 31 01:12:30 2009
[dgd]
Quixadhal@Bloodlines: Right, which is why we need a spreadsheet, so we can work out the curve.
Sun May 31 01:13:06 2009
[dgd]
Aidil@Way of the Force: mostly on the complexity of your npcs and how intensively they get busy using that complexity.. players? you should be fine till around 200 concurrent players given enough memory (also a function of world size and player activity)
Sun May 31 01:14:29 2009
[dgd]
Quixadhal@Bloodlines: If I could have 50 players and 2000 npcs doing average player/npc things and still be at half CPU, there's no reason to keep the tick count so low. If 50 npcs chew things up so bad the players can't type, then no more ansi colour for them! ;)
Sun May 31 01:15:35 2009
[dgd]
Aidil@Way of the Force: 2000 dumb npcs will hardly cause any cpu load, 20 very busy ones might cause a lot of load.
Sun May 31 01:17:06 2009
[dgd]
Aidil@Way of the Force: you can draw the curve for defined cases (mix of 10% wandering npcs vs 90% non wandering npcs, no AI) and default world :)
Sun May 31 01:17:15 2009
[dgd]
Quixadhal@Bloodlines: Right, that's where the tick count stuff comes into play though. If I make 20 npcs all run around using A* to find each other, I expect them to run out of ticks... but where will my CPU be? 10%, 50%, 99%? I sense that with the current settings, it won't be above 10% actual use.
Sun May 31 01:18:17 2009
[dgd]
Aidil@Way of the Force: I can easily get my p4ee 3.2ghz (single core) to 100% with a few hundred fast wandering npcs
Sun May 31 01:21:08 2009
[dgd]
Aidil@Way of the Force: problem with tick count is that for time sharing in a cpu constrained situation it functions as duration of a timeslice, but it also puts a limit on how much you can do codewise.
Sun May 31 01:22:21 2009
[dgd]
Aidil@Way of the Force: for the first, making it shorter gives the system a better chance of staying responsive, but for the later, it makes life harder.
Sun May 31 01:23:17 2009
[dgd]
Quixadhal@Bloodlines: My current idle DikuMUD has 723 mobiles loaded at the moment, I'd guess 30% of them wander. My CPU is at 0.9% I expect an LP to be much heavier, but it shouldn't be more than 10x as bad.
Sun May 31 01:23:53 2009
[dgd]
Aidil@Way of the Force: wander, not run around like madmen tho I suppose :)
Sun May 31 01:24:04 2009
[dgd]
Quixadhal@Bloodlines: That's why I wish thread didn't abort when they ran out of ticks... if they got shelved and restored, things would just become slower, rather than breaking.
Sun May 31 01:24:44 2009
[dgd]
Aidil@Way of the Force: well, you may want to take a peek at /kernel/cmds/admin/warmboot.c for a way to get around that :P
Sun May 31 01:25:01 2009
[dgd]
Quixadhal@Bloodlines: Rather like the OS does when it switches task execution... except LPC has a lot more registers to save and restore.
Sun May 31 01:25:32 2009
[dgd]
Aidil@Way of the Force: ticks are of little concern there.. but not being able to read every object from swap in a single thread is.
Sun May 31 01:26:26 2009
[dgd]
Aidil@Way of the Force: it also has to deal with certain things only happening at the end of a thread.
Sun May 31 01:27:15 2009
[dgd]
Aidil@Way of the Force: event_d does the same, in that case because of tick usage and to ensure it doesn't hog the system.
Sun May 31 01:29:10 2009
[dgd]
Aidil@Way of the Force: there is a very silly increasing of a global var in the dispatch_event() function now to force dgdmp to serialize the sequential calls to dispatch_event
Sun May 31 01:31:34 2009
[dgd]
Quixadhal@Bloodlines: Sure, I know there are ways around it (I had to use them in ansi_d!), but they require the builder who's coding some seek-and-destroy mob to realize this and work around it. I'd rather have threads put to sleep and just get slower, myself. Assuming I have a way to see that it's happening so I can smack people.
Sun May 31 01:32:34 2009
[dgd]
Quixadhal@Bloodlines: I know... it was designed for batch programming. :)
Sun May 31 01:33:02 2009
[dgd]
Aidil@Way of the Force: more point in dealing with the consequence :P
Sun May 31 01:33:58 2009
[dgd]
Quixadhal@Bloodlines: Yes, I suspect it's not impossible to change the way the driver handles it... but that level of black magic is a bit more than I want to work with.
Sun May 31 01:34:11 2009
[dgd]
Aidil@Way of the Force: but for a simple test for yourself, do an eval with an infinite loop, and see how long it takes to return an out of ticks error, and you have at least some idea.
Sun May 31 01:34:52 2009
[dgd]
Aidil@Way of the Force: well, I am not going to, and it makes things pretty much incompatible with unpatched versions of the driver, which makes it a nogo.
Sun May 31 01:37:00 2009
[dgd]
Quixadhal@Bloodlines: I wonder what a mudlib that expects threads to abort on ticks exceeded would DO if they didn't? I smell trouble.
Sun May 31 01:37:50 2009
[dgd]
Aidil@Way of the Force: prob seems more a lib that expects suspend/resume getting aborted instead :)
Sun May 31 01:38:21 2009
[dgd]
Quixadhal@Bloodlines: Hmmm, interesting. I did "eval while(1) a=1;" and got an expected out of ticks error almost at once. However, the next eval I did ("eval return time();") also gave me an out of ticks error.
Sun May 31 01:43:03 2009
[dgd]
Aidil@Way of the Force: btw, something that might be useful for this is allowing code to request more ticks based on real time measurement.
Sun May 31 01:44:19 2009
[dgd]
Aidil@Way of the Force: /kernel/sys/driver.c, runtime_rlimits() is the place where you could allow such a thing.
Sun May 31 01:47:07 2009
[dgd]
Quixadhal@Bloodlines: Interesting. I'd want to get at the current cpu load, or have some other averaged metric to make such a decision.
Sun May 31 01:48:12 2009
[dgd]
Quixadhal@Bloodlines wonders if lpc code could read through a symbolic link to /proc/loadavg
Sun May 31 01:48:43 2009
[dgd]
Aidil@Way of the Force: or look at the number of short term callouts + connections and decide what you'd accept as max response time.
Sun May 31 01:49:17 2009
[dgd]
Aidil@Way of the Force: that may work, but, read the mailinglist on shentino's earlier experiments in that direction and Dworkin's comments on it :)
Sun May 31 01:50:23 2009
[dgd]
Aidil@Way of the Force: not as such, he actually fixed dgd to make it work at all.
Sun May 31 01:51:31 2009
[dgd]
Quixadhal@Bloodlines: DGD is clever enough to resolve symlinks and check permissions against the target, isn't it? Or does it just ignore symlinks entirely?
Sun May 31 01:51:59 2009
[dgd]
Aidil@Way of the Force: but, you could do that :) catting it every so often to a file would work as well. but hmm. I'd rather approach it from trying to guarantee staying within a specific amount of latency.
Sun May 31 01:52:57 2009
[dgd]
Aidil@Way of the Force: which would come down to dividing your desired max latency by the number of connections + short time callouts.
Sun May 31 01:53:24 2009
[dgd]
Quixadhal@Bloodlines: Here's a question... which is cheaper... opening/reading/close a file, or having a network socket to an external script that sends data on request?
Sun May 31 01:54:17 2009
[dgd]
Aidil@Way of the Force: but, keep in mind that you'll get an answer in a seperate thread.
Sun May 31 01:54:35 2009
[dgd]
Quixadhal@Bloodlines: Sounds like a small perl daemon that dgd connects to at boot would be the best way to handle getting outside data in.
Sun May 31 02:03:38 2009
[dgd]
Aidil@GurbaDev2: eval a = millitime(); catch { rlimits( MAX_DEPTH; MAX_TICKS/2) { while(1) { } } } : { b = millitime(); write( dump_value(a)+"\n"+dump_value(b)); }
Sun May 31 02:10:03 2009
[dgd]
Aidil@GurbaDev2: eval a = millitime(); while(status()[23] > 500000 ) { } b = millitime(); write( dump_value(a)+"\n"+dump_value(b));
Sun May 31 02:11:30 2009
[dgd]
Aidil@GurbaDev2: but, on this little machine, that runs in approx 0.02 sec.
Sun May 31 02:15:11 2009
[dgd]
Aidil@GurbaDev2: ah, Dworkin fixed both crashes in dgdmp that I found :)
Sun May 31 02:15:39 2009
[dgd]
Aidil@GurbaDev2: or at least found what caused them and knows how to fix them.
Sun May 31 02:24:54 2009
[dgd]
Quixadhal@Bloodlines: Ack, no auto-promotion from int to float.... waaaah.
Sun May 31 02:36:12 2009
[dgd]
Quixadhal@Bloodlines: eval return status()[23] > 8019; takes 46 ticks
Sun May 31 02:37:08 2009
[dgd]
Quixadhal@Bloodlines: eval a = millitime(); while(status()[23] > 8019 ) { } b = millitime(); write( "" + ((float)(b[0] - a[0]) + (b[1] - a[1])) + "\n"); 8019 is the smallest number I can use that doesn't yield an out of ticks error.
Sun May 31 02:40:20 2009
[dgd]
Quixadhal@Bloodlines: with a 37 tick empty loop body, and a 46 tick evaluation condition, I was really expecting to be able to get down to within 200 or so ticks of my limit.
Sun May 31 02:41:04 2009
[dgd]
Quixadhal@Bloodlines: maybe 300.. I do have a little math on the end.. is the write that expensive?
Sun May 31 02:42:37 2009
[dgd]
Quixadhal@Bloodlines: eval a = millitime();b =millitime(); write( "" + ((float)(b[0] - a[0]) + (b[1] - a[1])) + "n"); yields 2654... still a mite shy of 8000.
Sun May 31 02:43:53 2009
[dgd]
Quixadhal@Bloodlines shrugs. Not like it matters all that much, but I'm curious where the rest of my ducks are being eaten. :)
Sun May 31 02:43:58 2009
[dgd]
Aidil@GurbaDev2: might be your out of ticks comes after the result and happens inside eval itself
Sun May 31 02:44:44 2009
[dgd]
Quixadhal@Bloodlines: I'm assuming eval can't cost more than 37, as that's what I get for "eval {}"
Sun May 31 02:45:39 2009
[dgd]
Quixadhal@Bloodlines: But, that's ok... I'm getting tired now and should probably let the idea ponder around dinner for a while.
Sun May 31 02:45:50 2009
[dgd]
Aidil@GurbaDev2: that is cause the measurement doesn't include most of the cost of eval
Sun May 31 02:48:17 2009
[dgd]
Aidil@GurbaDev2: hey, I argue a lot with people like shentino and dworkin :)
Sun May 31 02:49:44 2009
[dgd]
Aidil@GurbaDev2: if you have a few days with really nothing else to do, try having a discussion about licensing with shentino :)
Sun May 31 02:50:15 2009
[dgd]
Quixadhal@Bloodlines: LOL, arguing with Dworkin is a bit like arguing with a Zen garden. You swear you almost saw a change, but then you realize you were just out of breath.
Sun May 31 02:51:11 2009
[dgd]
Quixadhal@Bloodlines: and that's why DGD hasn't morphed into MudOS yet. :)
Sun May 31 03:32:53 2009
[dgd]
Kalinash@Fire and Ice: they're not saying "sleep", they're saying "drink"
Sun May 31 10:39:44 2009
[dgd]
Aidil@GurbaDev2: ok. Dworkin found his fiddling with Gurbalib expiring it seems, and rather likes the userland tls idea I added very recently :)
Sun May 31 10:53:11 2009
[dgd]
Aidil@GurbaDev2: looks like he found it inspiring, at least wrt tls use :)
Sun May 31 11:11:25 2009
[dgd]
Aidil@GurbaDev2: hmm.. this is kinda dangerous.. got me a new espresso machine.. Making me a nice coffee or capuchino is a matter of pressing a button instead of 10 mins of fiddling with a grinder, filling a piston with coffee, tampering it, hoping you get it right, and then paying attention to get the right amount of water..
Sun May 31 12:13:17 2009
[dgd]
Subversion@Way of the Force: Aidil committed Gurbalib revision 264 to svn://wotf.org/gurbalib : Added comments to the stack security system, added documentation for the (non kernel) api for it
Sun May 31 12:29:24 2009
[dgd]
Aidil@GurbaDev2: oh Quixadhal, something you may want to know for your little eval tests
Sun May 31 12:29:51 2009
[dgd]
Aidil@GurbaDev2: things like "boo" + 1 or other literals in a calculation or comparison are handled at compiletime.
Sun May 31 12:30:23 2009
[dgd]
Aidil@GurbaDev2: so write("boo") and write("boo" + 1) have an identical cost.
Sun May 31 12:54:19 2009
[dgd]
Subversion@Way of the Force: Aidil committed Gurbalib revision 265 to svn://wotf.org/gurbalib : Arguments on the call stack are no longer visible to code outside /kernel
Sun May 31 13:08:44 2009
[dgd]
Aidil@GurbaDev2: oh hmm, and another note on max ticks and dgdmp, the higher the number of ticks yo use on average, the bigger the chance on thread collisions and the more expensive rollbacks will be.
Sun May 31 13:09:22 2009
[dgd]
Aidil@GurbaDev2: getting more rollbacks that are also more expensive isn't going to do well for your cpu utilisation, eventho it will easily hit 100%
Sun May 31 13:11:19 2009
[dgd]
Aidil@GurbaDev2: but will mostly be busy trying and aborting transactions.
Sun May 31 13:56:12 2009
[dgd]
Subversion@Way of the Force: Aidil committed Gurbalib revision 266 to svn://wotf.org/gurbalib : Added symbol caching to the ansi daemon, small change to the user object to allow using more ticks during user output
Sun May 31 13:58:07 2009
[dgd]
Aidil@GurbaDev2: the gain from the caching isn't as big as I was hoping for, but on really large strings it is in the order of 25% still.
Sun May 31 13:59:01 2009
[dgd]
Aidil@GurbaDev2: hmm. that said, I see a way to optimize the caching a bit :) coffee first tho.
Sun May 31 14:26:20 2009
[dgd]
Subversion@Way of the Force: Aidil committed Gurbalib revision 267 to svn://wotf.org/gurbalib : Optimized caching in ansi_d
Sun May 31 14:32:26 2009
[dgd]
Aidil@GurbaDev2: heh. between the last 2 commits, ansi_d won't run out of ticks now, but will run out of array size with the default settings :)
Sun May 31 17:12:00 2009
[dgd]
Subversion@Way of the Force: Aidil committed Gurbalib revision 268 to svn://wotf.org/gurbalib : Performance enhancement to the set_tlvar afun, added support for per object tls variables
Sun May 31 20:32:20 2009
[dgd]
Subversion@Way of the Force: Aidil committed Gurbalib revision 269 to svn://wotf.org/gurbalib : Changed parse_d to use a per object tls variable, added a check to ansi_d to prevent the symbol cache from becomming too large
Sun May 31 22:14:22 2009
[dgd]
Subversion@Way of the Force: Aidil committed Gurbalib revision 270 to svn://wotf.org/gurbalib : Imported unpatched dgd source to ease creating distributions
Mon Jun 1 11:52:44 2009
[dgd]
Subversion@Way of the Force: Aidil committed Gurbalib revision 271 to svn://wotf.org/gurbalib : Make the event dispatcher a lot more efficient (no longer uses a seperate 0 delay call_out for each subscriber)
Mon Jun 1 12:00:37 2009
[dgd]
Aidil@GurbaDev2: oh, and that change uses the 'call_out cantrip' idea Shentino and me were discussing a while ago on the dgd mailinglist.
Mon Jun 1 12:01:05 2009
[dgd]
Aidil@GurbaDev2: ie, modify the arguments to a called out function after the call_out has been started.
Mon Jun 1 12:22:05 2009
[dgd]
Aidil@Way of the Force: right.. now that I got Dworkin to look at gurbalib.. next step is to get him to join the dgd channel on i3 :)
Mon Jun 1 13:00:44 2009
[dgd]
Subversion@Way of the Force: Aidil committed Gurbalib revision 272 to svn://wotf.org/gurbalib : Make unguarded() throw an error when it can't find the function provided as argument, remove depricated lib/daemons/convert_d.c, fix save_me/restore_me functions in lib/daemons/* to deal with the stack based security system
Mon Jun 1 18:32:20 2009
[dgd]
Subversion@Way of the Force: Aidil committed Gurbalib revision 273 to svn://wotf.org/gurbalib : Better protection against running out of ticks during event handling, added some optional debugging output to the event_d (add #define DEBUG_EVENT_D to /include/local_config.h to enable)
Mon Jun 1 18:33:18 2009
[dgd]
Aidil@Way of the Force: oh, and Quixadhal, you may wanna look at the code I just committed :)
Tue Jun 2 19:38:21 2009
[dgd]
Aidil@Way of the Force: no mischan this time.. looks like dgdmp 1.1.9 fixes some nice scheduler issues. Having 12000 npcs running around without noticable lag :)
Tue Jun 2 19:39:06 2009
[dgd]
Aidil@Way of the Force: now lets do some reoptimizing of the event_d for it.
Thu Jun 4 00:41:12 2009
[dgd]
Quixadhal@Bloodlines: Hmmmm, now, make 6000 of them green, and 6000 of them purple, and see who's the last NPC standing. Bonus points if you spot the sci-fi reference. *grin*
Thu Jun 4 03:34:44 2009
[dgd]
Subversion@Way of the Force: Nullinfinite committed Gurbalib revision 274 to svn://wotf.org/gurbalib : Objects can now define their own verbs and verb rules.
Thu Jun 4 21:22:25 2009
[dgd]
Quixadhal@Bloodlines-VM: Both these muds show up as the same address and port. :)
Thu Jun 4 21:24:10 2009
[dgd]
Quixadhal@Bloodlines-VM: I can see someone out there having an SQL database that's unique by the joint key IP + Port though, and I just confused them.
Thu Jun 4 21:30:28 2009
[dgd]
Quixadhal@Bloodlines-VM: Oh, it may be worth stuffing into an NSFAQ somewhere... To clone your gurba brand mud to a development copy, and have them both on I3, you need to remove /lib/daemons/data/imud_d.o, and also edit /lib/kernel/include/mudname.h
Thu Jun 4 21:32:27 2009
[dgd]
Quixadhal@Bloodlines-VM: Don't make me commit a two-line text file... "Q1) Where is the FAQ? A1) Right here. EOF" :)
Thu Jun 4 22:10:12 2009
[dgd]
Quixadhal@Bloodlines-VM: Oh, I have been informed that tomorrow is National Doughnut Day (in America, anyways). :)
Fri Jun 5 08:57:43 2009
[dgd]
Quixadhal@WileyMUD: No emotes for us old DikuMUD folk... they're not a seperate command table. :)
Fri Jun 5 10:31:36 2009
[dgd]
Quixadhal@Bloodlines: Crashed when I copied it from the test mud to the semi-live one, probably some cached data that flaked
Fri Jun 5 10:32:00 2009
[dgd]
Quixadhal@Bloodlines: Yeah, it's also the ONLY thing that has ANSI colour in that mud. Looks very strange.
Fri Jun 5 10:33:38 2009
[dgd]
Quixadhal@WileyMUD: Yep, must have been flaky cached data. This is via the dalet IMC gateway.
Fri Jun 5 10:34:20 2009
[dgd]
Aidil@The Zone welcomes WillyMUD to the modern age of intermud communications.
Fri Jun 5 10:35:18 2009
[dgd]
Quixadhal@WileyMUD: Added bonus, I found a bug that nuked skill settings that got added when I upgraded compilers a few months ago.... yeah, it's quiet here.
Fri Jun 5 10:39:08 2009
[dgd]
Quixadhal@Bloodlines: Yes *grinds teeth*, it's a great tool for language creativity.
Fri Jun 5 10:40:24 2009
[dgd]
Aidil@The Zone: and heh.. quiet eh? :) about a week ago I fixed a bunch of pretty obvious bugs on Way of the Force that got introduced by a major lib change a year ago, and that noone noticed during that time :P
Fri Jun 5 10:41:09 2009
[dgd]
Quixadhal@Bloodlines: Heh, well... if I had any actual players, I'm sure they would have sent me email telling me that ALL of their skills were now "unlearned" every time they logged back in.
Fri Jun 5 10:42:00 2009
[dgd]
Quixadhal@Bloodlines: Something about looking up the skill by name, but passing it a pointer to the pointer that was moved to the end, rather than the start of the string. :)
Fri Jun 5 10:42:04 2009
[dgd]
Aidil@The Zone: I found the bugs coz there are some actual players on way of the force, and 2 of them are pretty good at bug hunting.. they aren't there very often tho.
Fri Jun 5 10:43:11 2009
[dgd]
Aidil@The Zone: but you have during the last year :) the bugs were introduced last year april.
Fri Jun 5 10:43:44 2009
[dgd]
Aidil@The Zone: Parham and Dethter took about 30 minutes to find them.. but then, they are pretty good at that :)
Fri Jun 5 10:44:36 2009
[dgd]
Aidil@The Zone: the follow and team systems were completely non functional.
Fri Jun 5 10:45:10 2009
[dgd]
Quixadhal@WileyMUD: See, over here that would just crash the game so you'd know right away... not WHERE mind you, but that it was broken. :)
Fri Jun 5 10:45:33 2009
[dgd]
Aidil@The Zone: well, not too surprised about the team one, but the follow one surprised me since it can also be used with npcs, and can be useful there.
Fri Jun 5 10:46:13 2009
[dgd]
Aidil@The Zone: better break with good information and without crash :)
Fri Jun 5 10:46:31 2009
[dgd]
Quixadhal@WileyMUD: I can tell if something crashed, as I'd have more than one logfile a day.
Fri Jun 5 10:46:35 2009
[dgd]
Aidil@The Zone: after noticing them, finding what was wrong and fixing it took all of 10 minutes :)
Fri Jun 5 10:47:44 2009
[dgd]
Aidil@The Zone: hmm, getting a bug reported, and being able to fix it in minutes and get the player a working version is kinda fun as well :)
Fri Jun 5 10:49:05 2009
[dgd]
Quixadhal@WileyMUD: Yep, I used to be able to do that. :) Then I got a job doing perl/SQL... now C code is a vegetable that I often skip.
Fri Jun 5 10:49:36 2009
[dgd]
Aidil@The Zone: hehe. well, can't skip on it here if I'm too maintain the dgd network package :)
Fri Jun 5 10:50:25 2009
[dgd]
Quixadhal@WileyMUD: Yes... the giant codebase I inherited back two jobs ago didn't "use strict" :(
Fri Jun 5 10:51:00 2009
[dgd]
Quixadhal@WileyMUD: Nor did it "use English"... I got to know "man perfunc" pretty quickly.
Fri Jun 5 10:51:07 2009
[dgd]
Aidil@The Zone: lets say that when dealing with networking, off by one errors can be really deadly.. :)
Fri Jun 5 10:51:52 2009
[dgd]
Frutsel@fruts: heh. how about perl written by 2 dyslexic 'programmers'
Fri Jun 5 10:52:18 2009
[dgd]
Quixadhal@WileyMUD: Interesting... I'm sending double-quotes, which I see on gurba... but here I see them as single-quotes.
Fri Jun 5 10:52:35 2009
[dgd]
Aidil@The Zone: heh, that is actually one of the more impressive features of perl..
Fri Jun 5 10:52:41 2009
[dgd]
Quixadhal@Bloodlines: I wonder if IMC loses "something" in the 'translation'?
Fri Jun 5 10:52:58 2009
[dgd]
Aidil@The Zone: even code written by 2 dyslexic programmers will somehow still work sortof.
Fri Jun 5 10:53:44 2009
[dgd]
Frutsel@fruts: it worked allright (sorta), because the misspelled words were consistently wrong
Fri Jun 5 10:53:53 2009
[dgd]
Quixadhal@WileyMUD: $$color = $$colour + 1; Find that mess in perl without use strict.
Fri Jun 5 10:53:59 2009
[dgd]
Aidil@The Zone: that double quotes work on gurbalib took a fair bit of fiddling btw :)
Fri Jun 5 10:54:40 2009
[dgd]
Quixadhal@WileyMUD: It's interesting, as it IS sending them, just translating all doubles into singles on incoming messages (including the echo of what I send).
Fri Jun 5 10:55:24 2009
[dgd]
Aidil@The Zone: maybe I should write me an imc2 client and server someday.
Fri Jun 5 10:55:38 2009
[dgd]
Quixadhal@WileyMUD: Oh well, no complaints... Hacking IMC support into a game driver that started running in 1993 is good enough.
Fri Jun 5 10:56:06 2009
[dgd]
Aidil@The Zone: then this mudlib sortof predates your gamedriver tho :)
Fri Jun 5 10:56:52 2009
[dgd]
Quixadhal@WileyMUD: The C code was a bit different under SunOS 3.x, on a Sun 3/60. :)
Fri Jun 5 10:57:39 2009
[dgd]
Quixadhal@WileyMUD: Had to rewrite socket handling AND signal handling twice.. once from SunOS/Solaris to BSD, and again from BSD to linux.
Fri Jun 5 10:58:23 2009
[dgd]
Aidil@The Zone: the rather funny part of that is that I have LPC code from Dworkin here that predates DGD.
Fri Jun 5 10:59:20 2009
[dgd]
Aidil@The Zone: the finger/player info daemon was also written by him, and goes back to mid 1990.
Fri Jun 5 11:00:05 2009
[dgd]
Aidil@The Zone: tho not much of that survived, mostly the function names and layout of the object are still somewhat recognizable.
Fri Jun 5 11:00:13 2009
[dgd]
Quixadhal@WileyMUD: It was a sad day when I found the updated varargs.h file for newer gcc's
Fri Jun 5 11:02:39 2009
[dgd]
Quixadhal@Bloodlines: So, out of curiosity.. have you guys seen any influx of players on wotf since the new star wars MMO was announced? :)
Fri Jun 5 11:03:50 2009
[dgd]
Aidil@The Zone: there is a low but relatively constant stream of new players checking it out, some of which stay around for a while, but that has been the case for the last 1 1/2 years.
Fri Jun 5 11:03:53 2009
[dgd]
Quixadhal@Bloodlines: I know most MMO folk who aren't our age have no idea text games even exist, but I was curious. Google does help one find all sorts of things.
Fri Jun 5 11:06:57 2009
[dgd]
Aidil@The Zone: no idea why, but I know way of the force wasn't the only mud seeing a sudden peak in player activity in june/july 2007
Fri Jun 5 11:12:04 2009
[dgd]
Aidil@The Zone: ha. kobramud is trying to get as many old players as possible to login in during the comming weekend.
Fri Jun 5 11:13:26 2009
[dgd]
Aidil@The Zone: to think that some decade ago, we had to upgrade the server due to player activity there.
Fri Jun 5 11:20:00 2009
[dgd]
Aidil@The Zone: so, did any of you try to run gurbalib with #define ENABLE_STACK_SECURITY added to /include/local_config.h yet?
Fri Jun 5 11:20:15 2009
[dgd]
Quixadhal@Bloodlines: I know... in WileyMUD's heyday, we had to write code to turn people away after 40 logins between 9am and 5pm, since it was on the campus news server.
Fri Jun 5 11:30:09 2009
[dgd]
Aidil@The Zone: kobramud has had its own dedicated server since the start, tho initially that was a borrowed ibm rt running aix of sorts.
Fri Jun 5 11:32:13 2009
[dgd]
Aidil@The Zone: in the mid 90s it was some pentium based machine running linux. by 1999 it was a dual p2 with lots of memory and a bunch of scsi disks in a mirroring config :)
Fri Jun 5 11:33:07 2009
[dgd]
Aidil@The Zone: that machine was finally depricated some 3 years ago :)
Fri Jun 5 11:33:53 2009
[dgd]
Aidil@The Zone: I still have the prototype we built for that server around :)
Fri Jun 5 11:34:59 2009
[dgd]
Quixadhal@Bloodlines: We started on a Sun 3/60 in a back office, moved to the news server (a Sparc 4/110), shut down, came back on a dedicated linux 486/133, shut down until I dragged it back out of hibernation. It's now on a P3/933 and could probably handle 200 players... it's only ever seen about 5. :)
Fri Jun 5 13:40:02 2009
[dgd]
Subversion@Way of the Force: Aidil committed Gurbalib revision 275 to svn://wotf.org/gurbalib : Fixed save/restore functions in board module to be compatible with the stack based security system, added some comments to the tls afuns
Mon Jun 8 16:02:43 2009
[dgd]
Subversion@Way of the Force: Aidil committed Gurbalib revision 276 to svn://wotf.org/gurbalib : Fixed upgrade error in parse_d
Tue Jun 9 02:38:06 2009
[dgd]
Subversion@Way of the Force: Nullinfinite committed Gurbalib revision 277 to svn://wotf.org/gurbalib : user->wrap_message no longer indents after each line, unless a varargs int is passed to the wrap_message function. This is a slight change to the interface, and several files modified to reflect the new flag.
Wed Jun 10 12:43:35 2009
[dgd]
Subversion@Way of the Force: Aidil committed Gurbalib revision 278 to svn://wotf.org/gurbalib : Make message() in monsters accept an optional second argument as well, and pass it on to a possible possessor
Wed Jun 10 21:08:56 2009
[dgd]
Aidil@Way of the Force: Shentino: I suppose there is such a thing as being *too* neat.
Wed Jun 10 21:09:57 2009
[dgd]
Aidil@Way of the Force: the 'neat' thing he thought up was to put variables, function declarations and definitions each in seperate inheritables.
Thu Jun 11 02:18:35 2009
[dgd]
Quixadhal@Bloodlines: I'm not a big OO fan, but I do agree that global variables are a solution of last resort.
Thu Jun 11 02:19:02 2009
[dgd]
Kalinash@Fire and Ice: think of it this way... "gloal" variables in an LPC object are just member variables ;)
Thu Jun 11 02:22:19 2009
[dgd]
Quixadhal@Bloodlines: Yes, but that doesn't make them much cleaner... especialy if it's something you inherit.
Thu Jun 11 02:25:41 2009
[dgd]
Quixadhal@Bloodlines: For example, you inherit "circle" and get the methods radius() and diameter(), but you also get this extra variable called "pi" and "center_x" and "center_y"? Sounds ugly to me.
Thu Jun 11 02:29:48 2009
[dgd]
Kalinash@Fire and Ice: then they should be private so you don't see them in a subclass
Thu Jun 11 02:30:53 2009
[dgd]
Kalinash@Fire and Ice: you can't actually have globals in the same sense as C or C++ in LPC since every file is it's own object
Thu Jun 11 02:31:06 2009
[dgd]
Kalinash@Fire and Ice: you can't share a single variable across objects
Thu Jun 11 02:45:37 2009
[dgd]
Quixadhal@Bloodlines: Then why put them in an inheritable? That's even more confusing. :)
Thu Jun 11 07:02:34 2009
[dgd]
Aidil@The Zone: hmm, Kal, Gurbalib has tls variables that are shared across objects :)
Fri Jun 12 06:01:19 2009
[dgd]
Quixadhal@WileyMUD-dev: Implemented a new string pager system... have I mentioned how much strings in C suck?
Fri Jun 12 09:12:06 2009
[dgd]
Aidil@The Zone: thats part of why much of the buffering for udp and tcp communications on dgd is implemented in lpc :)
Fri Jun 12 09:16:30 2009
[dgd]
Quixadhal@Bloodlines: In this case, I needed to change the pager, because the one we wrote 10+ years ago assumed you'd stuff one big string into it at a time.
Fri Jun 12 09:17:22 2009
[dgd]
Quixadhal@Bloodlines: If one does the mudlist that way, it doesn't actually get to page... the new one breaks things up by lines and makes a linked list of them. :)
Fri Jun 12 09:17:57 2009
[dgd]
Aidil@The Zone: string wrapper and network buffering are pretty similar actually :)
Fri Jun 12 09:18:47 2009
[dgd]
Quixadhal@Bloodlines: Yep, although you can't use fun things like strpbrk() with packets, since they may have NUL's in the middle.
Fri Jun 12 09:19:38 2009
[dgd]
Quixadhal@Bloodlines: I hate to say it, but Pascal had strings right (leading length-count vs. NUL terminated).
Fri Jun 12 09:20:28 2009
[dgd]
Aidil@The Zone: DGD's strings are pretty similar, but they have length as property of the object instead of in front of the string
Fri Jun 12 09:21:43 2009
[dgd]
Quixadhal@Bloodlines: My ideal language would have the brevity and pure-OO nature of ruby, but with python's formatting. If you do a little python, you realize how nice it is to have the indentation BE your begin/end markers.
Fri Jun 12 09:23:01 2009
[dgd]
Quixadhal@Bloodlines: Yes, but it's not really the whitespace, it's the consistent indentation levels that matter. You DO indent your code consistently, no?
Fri Jun 12 09:23:30 2009
[dgd]
Aidil@The Zone: yes, but how I do that is none of the languages business.
Fri Jun 12 09:24:35 2009
[dgd]
Quixadhal@Bloodlines: Well, python doesn't care how far you indent, or if you use tabs/spaces/whatever... it just sees the next line having more whitespace than the last and will treat that as a begin until something comes along with less whitespace (skipping comments and blank lines, of course).
Fri Jun 12 09:25:40 2009
[dgd]
Quixadhal@Bloodlines: Having been forced to do FORTRAN with it's weird columns having special meanings, I thought I'd hate it too until I tried it. :)
Fri Jun 12 09:25:42 2009
[dgd]
Aidil@The Zone: I understand what python does, and to me it mixes language structure and syntax with being 'pretty to read'.
Fri Jun 12 09:26:49 2009
[dgd]
Quixadhal@Bloodlines: It does mean you can't easily have an obfuscated python contest, I suppose.
Fri Jun 12 09:28:13 2009
[dgd]
Quixadhal@Bloodlines: It also means you can't do weird crap like perl's "print poo or die 'in agony' if !broken;"
Fri Jun 12 09:28:33 2009
[dgd]
Aidil@The Zone: a human brain doesn't work like a machine, hence it seems a flawed approach to use what is aaimed at human brains for a machine and the other way around
Fri Jun 12 09:29:10 2009
[dgd]
Aidil@The Zone: pretty to read should have nothing to do whatsoever with syntax, different target, different purpose.
Fri Jun 12 09:29:28 2009
[dgd]
Aidil@The Zone: when you do link the 2 as python does, you will sacrifice one of both.
Fri Jun 12 09:30:26 2009
[dgd]
Aidil@The Zone: it is the same argument basicly as mixing functionality and layout in html, just that the conseuqence is much more pronounced and obvious in the later case.
Fri Jun 12 09:30:43 2009
[dgd]
Quixadhal@Bloodlines: perhaps. Although the machine would be just as happy to have no whitespace at all, and if you hand me that kind of code, I just delete it and pretend you never sent it.
Fri Jun 12 09:31:32 2009
[dgd]
Quixadhal@Bloodlines: As someone who hand writes html, I also indent that so I can follow it. I've looked at what "frontpage" does, and don't wish that on anyone.
Fri Jun 12 09:31:38 2009
[dgd]
Aidil@The Zone: and a programming language that tries to force such a choice is stepping outside its boundaries.
Fri Jun 12 09:32:43 2009
[dgd]
Aidil@The Zone: the SOLE argument that I am making is that it is none of the business of a programming language.
Fri Jun 12 09:33:52 2009
[dgd]
Quixadhal@Bloodlines: So, *I* would be happier if the HTML spec didn't allow such garbage. For the same reason, I like python imposing some level of neatness. It may be overbearing, but it's not like it prevents you from expressing anything, other than hard-to-follow chunks of source code.
Fri Jun 12 09:34:35 2009
[dgd]
Quixadhal@Bloodlines: One of the reasons I hated Pascal and liked C was the brevity... I couldn't see why we needed to spell out "BEGIN" and "END", when { and } worked just fine. Same idea.
Fri Jun 12 09:36:04 2009
[dgd]
Quixadhal@Bloodlines: Yes, but my point is that you're going to indent code in a way that makes sense anyways... what's wrong with using that?
Fri Jun 12 09:36:44 2009
[dgd]
Quixadhal@Bloodlines: If you want some special amount of whitespace for some asthetic reasons... you can always make the line a comment.
Fri Jun 12 09:37:29 2009
[dgd]
Aidil@The Zone: sorry, that sounds like making excuses for why mixing 2 things that shouldn't be mixed isn't as bad.
Fri Jun 12 09:38:39 2009
[dgd]
Aidil@The Zone: layout is simply none of the business of the programming language, and despite liking nicely idented code, I see no reason why a language should enforce that or even worse, assign some kind of meaning to it.
Fri Jun 12 09:39:13 2009
[dgd]
Quixadhal@Bloodlines: I don't see it as bad. If it forced me to use 4-space indents, or something, that'd be bad. When it's just going to make use of something I *already* intend to do, and save me typing in the process, I have no issues with it.
Fri Jun 12 09:40:28 2009
[dgd]
Quixadhal@Bloodlines: To me, the goal of a programming language is to let me express my ideas to the machine as simply as possible. If it could read my mind without me typing at all, that would be ideal.
Fri Jun 12 09:40:49 2009
[dgd]
Aidil@The Zone: when mixing layout and function, you will run into restrictions in use that you won't easily forsee.
Fri Jun 12 09:41:41 2009
[dgd]
Quixadhal@Bloodlines: That's why we have 20,000 languages to choose from. :)
Fri Jun 12 09:42:02 2009
[dgd]
Aidil@The Zone: to me it seems a bad idea, regardless of if I intent to indent my code or not, because that choice simply isn't any of the language's business.
Fri Jun 12 09:43:58 2009
[dgd]
Quixadhal@Bloodlines: http://free-idea-monoid.blogspot.com/2009/05/code-layout-experiements.html
Fri Jun 12 09:45:44 2009
[dgd]
Aidil@The Zone: anyway, Quix, no need to convince me of the use of layout and indentation. If you want to convince me, you'll have to convince me of why exactly it is a good idea to REMOVE choice for the programmer in this. You being able to read the code? how about using an indent program on it? problem solved.
Fri Jun 12 09:48:02 2009
[dgd]
Silenus@Dead Souls Dev: I wonder if this is an actual proposal or not
Fri Jun 12 09:48:07 2009
[dgd]
Silenus@Dead Souls Dev: http://www.research.att.com/~bs/whitespace98.pdf
Fri Jun 12 09:48:10 2009
[dgd]
Aidil@The Zone: for that matter, the only somewhat convincing argument for the 'python way' that I have heard so far is that it teaches newbie coders to do it right.
Fri Jun 12 09:48:46 2009
[dgd]
Aidil@The Zone: since you spend much more time using a language then learning one usually, that seems a rather limited 'good reason'.
Go to the top | Channel Index

